DIBEngine and gdi32/user32 controls drawing loop performance

June 20, 2010

      Hello,

   since I had a poor performance in drawing many buttons and text input
 fields at the same time into a window with wine, I applied the 
DIBEngine patch (http://wiki.winehq.org/DIBEngine) 
that is available for wine 1.1.44 (http://bugs.winehq.org/attachment.cgi?id=27879) to 
the 1.1.44 version of wine and started my application program that needs
 to draw many button and text input fields in a single window with the 
enviroment variable "WINEDIB=ON wine 
./App.exe".

   Now that the DIBEngine patch is applied a little speedup in the 
drawing of the buttons and the text input fields is shown, but now the 
problem is that they are still drawn in blocks of a subset of the total 
number and then wine waits a little bit, then it draws another block of 
text input fields and buttons and then wine still waits, then it draws, 
and so on. The result is that my App.exe application window that is full
 of buttons and text input fields is drawn in subsequent times, and 
groups of buttons and input fields are drawn in blocks with a delay 
between the drawing of a group of controls and the others.

    The fact that not all the controls are drawn at a time but in more 
times is frustrating, since the CPU is a core2duo, and I think that it 
is powerful enough to draw all of the controls in the window at a time, 
specially with the DIBEngine patch applied and the DIBEngine activated. 
So I thought that the problem could be in the main event loop that 
manages the App.exe application window, and in particular the problem 
could be that the loop yields the drawing of the controls after a 
certain number of controls have been drawn in order to avoid CPU high 
load and then the loop starts again to draw other controls after a while
 and then it stops and yields and waits again, and so on.

    Where can I modify such a behaviour? In particular my App.exe 
program use many gdi32 drawing commands for drawing buttons and text 
input fields, so the files dlls/user32/button.c and dlls/user32/edit.c 
are involved. I think that the dlls/user32/winproc.c file, where the

 	  Code:
			  LRESULT WINAPI EditWndProcA( HWND hwnd, 
UINT msg, WPARAM wParam, LPARAM lParam )

{

    return wow_handlers.edit_proc( hwnd, msg, wParam, lParam, FALSE );

}	

function is defined is the file where I should do some changes; this 
function calls

 	  Code:
			  LRESULT EditWndProc_common( HWND hwnd, 
UINT msg, WPARAM wParam, LPARAM lParam, BOOL unicode )

that is implemented in the dlls/user32/edit.c file, but the fact is that
 in the EditWndProc_common function there are many cases like this one 
that manages the various edit messages and window messages sent 

 	  Code:
			     switch (msg) {

   case EM_GETSEL:

      result = EDIT_EM_GetSel(es, (PUINT)wParam, (PUINT)lParam);

      break;

        ....	

and I don't know how to modify the fact that the main loop of the window
 should handle more messages in order to draw all of the controls at a 
time and that it should not yield for waiting and then starting drawing 
again after some time.

What can I do?

Thanks in advance,

AmoxT 		 	   		  
_________________________________________________________________
Taglia i costi. Chiama e videochiama da Messenger
http://www.messenger.it/videoconversazioni.aspx

Amico Amico

James McKenzie

tags

participants (2)