DIBEngine and gdi32/user32 controls drawing loop performance
Amico Amico
amos.t at hotmail.it
Sun Jun 20 09:29:21 CDT 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100620/c630b0f1/attachment.htm>
More information about the wine-devel
mailing list