Improving performance for the current multi-window mode

[Harold L Hunt II]

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