wine users - Jun 2010 - DIBEngine and gdi32/user32 controls drawing loop performance

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

On 2010-06-20 (June, Sunday) 08:11:15 AmoxT wrote:
> What can I do?
	Ask your question in wine-devel mailing list. Most developers don't even
read
wine-users mailing list (this forum). And you obviously need help from 
developer who understands DIB engine in question.

Yes, you're right!
Thanks! :)

AmoxT