This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Improving performance for the current multi-window mode
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygx <cygwin-xfree at cygwin dot com>
- Date: Sun, 11 Jan 2004 20:03:16 -0500
- Subject: Improving performance for the current multi-window mode
- Reply-to: cygwin-xfree at cygwin dot com
I have wanted to add DirectDraw support to the current multi-window mode
for some time now. I never really sat down and reviewed the current
code until now to see whether this was really feasible or not. Here are
my initial observations:
1) The multi-window code only calls the GDI BitBlt function in
winmultiwindowwndproc.c/WM_PAINT.
2) The WM_PAINT messages in #1 are due either to normal Win32 window
expose messages or they are fired from
winshadgdi.c/winRedrawAllProcShadowGDI.
3) winshadgdi.c/winRedrawAllProcShadowGDI is called from the following
locations:
winshadgdi.c/winRedrawScreenShadowGDI
winshadgdi.c/winInstallColorMapShadowGDI
winshadgdi.c/winAllocateFBShadowGDI
winshadgdi.c/winShadowUpdateGDI
4) The last location in #4 is very important: It means that every time
that winShadowUpdateGDI gets called (which is done possibly dozens of
times per second), we call winRedrawAllProcShadowGDI for *each* window
that has been created in multi-window mode, telling *each* window to
copy their entire contents from the shadow buffer, regardless of whether
that window has actually been updated or not. This explains part of the
relatively poor performance of the current multi-window mode. There are
many possible ways to limit the number of windows that need to have
their contents redrawn: 1) You can check if the bounding rectangle on
the updated region intersects with each window before redrawing their
contents, 2) You can create a region that represents the intersection
between the clipping region for each window and the update region and
proceed to redraw each window, which would only touch windows that had
updated content, 3) You could rewrite the winShadowUpdateGDI function to
do several blits that are clipped to each window and to the updated
regions, removing the need for calling winRedrawAllProcShadowGDI in that
case. Some very small changes to this code could result in a big
performance boost for multi-window mode.
5) Because the BitBlt calls are restricted to the WM_PAINT messages and
because the DirectDraw primary surface exposes the entire screen for Blt
calls, we should be able to create engine-specific functions to handle
the WM_PAINT messages in multi-window mode. For DirectDraw this
function would need to adjust the clipping region for the clipper that
we attach to the primary surface, then do a DirectDraw Blt to update the
current window's contents.
None of this is particularly hard to fix. I am in the middle of looking
at item #5 and I may have something soon. Ultimately, item #4 needs to
be fixed, unless we switch over to Kensuke's new XWinWM soon (which
should fix such problems, I hope).
Happy hacking to anyone that decides to help with #4 and #5!
Harold