DIBEngine and gdi32/user32 controls drawing loop performance
jjmckenzie51 at earthlink.net
Sun Jun 20 10:20:34 CDT 2010
Amico Amico wrote:
> 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.
This does duplicate Windows performance as not all controls are drawn at
the same time. If you used a slower/older machine this is very
apparent. Because of the delays induced by Wine's use of opengl this
> 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.
This is what Windows does as well. It is very interesting to watch on
my older PIII/750 machine running WindowsXP.
However, if you feel that you can improve performance, you are welcome
I plan on picking up and examining the DIB Engine code after the release
of Wine 1.2 and building a few more features that are missing from richedit.
More information about the wine-devel