This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Improving performance for the current multi-window mode


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]