[Wine] Re: Poor performance while drawing text input fields and buttons

[AmoxT]

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