Some news about my DIB Engine.....

[Massimo Del Fedele]

I've gone a bit further with my DIB Engine, mostly on gdi32 side, in 
order to solve the last problems, at least as seen in my favorite app, 
Autocad 2005.
Previous version had a bug related to the *only* .net part of that app 
(which was obviously written by a 5 years old child, imho), the layer 
manager.
On this one, a bitblt operation is done reading some screen part into a 
DIB when painting the dialog on screen.
Worse than that, there are *many* small bitblt ops (like 40x1 pixels) on 
*large* source/destination bitmaps (like some hundred kB - MB of pixel data.
Well, that stuff showed to me the big limit of the approach taken, the 
"mixed driver" one with different driver pointers on same DC.
That's the approach taken by earlier intents of Jesse Allen and Huw Davies.
So I decided to make a break, examining the problems so far and maybe 
discussing a bit about it.

1) Maintain DCs and bitmaps in sync with correct driver.
That problem is fully solved, requiring some small hacks on many parts 
of gdi32, in detail in bitmap.c, dib.c and dc.c.
Well, not really hacks, even if the code isn't as clean as I'd like.
Difficulty here was mostly due to bmp funcs that should be identical to 
DC on which it's selected, on DIB creation and on BITMAP_SetOwnerDC() 
part. In short, that part should be quite good by now.

2) Now the big (and slow) problem : the "mixed" operations, those which 
uses both DIBs and DDB; BitBlt(), StretchBlt and so on.
On those we can't simply use one driver because it can't handle other 
driver's bitmap. Well, X11 driver could do it, in theory, but having the 
DIB created by DIB engine makes it impossible (missing X11 physDev and 
related pixmap).
So the problem, as correctly pointed by Jesse Allen, is to "uniformize" 
the DCs *before* the BlitBlt operation, *or* to make DIB engine able to 
deal with DDB stuffs.
I discarded latter approach for obvious reasons, the engine would become 
a copy of X11 driver with added DIB stuffs, which would vanify the 
(simpler) approach taken. BTW, I'm still convinced that the "right" 
approach would be to rewrite X11 driver withe the engine embedded, OR to 
embed the engine on gdi32 taking it off X11 driver.
Well, back to first approach, Jesse's one. It means to make a copy of 
the source bitmap *before* blitting converting it on same format of 
destination one. That approach is slower because it means to make a copy 
/conversion of the source bitmap which can be time expensive.
Jesse's solution was to make a conversion of the *full* source bitmap 
which showed it's first limit on my Autocad testings (the layer manager 
part) on whith very small parts of a big image are Blitted. That means 
sometimes hundreds of copy/conversions of a MB sized bitmap just to 
transfer some 40 pixels a time..... not a real speed gain :-)
So I decided to limit the copy of the needed lines of source bitmap, 
with help of GedDIBits/SetDIBits stuffs. Not perfect, but quite 
faster..... *if* working.
SetDIBits seems to have some sort of bug when "startscan" and 
"scanlines" don't use the full bitmap's size. I'm not able to test the 
SetDIBits X11 code, so if somebody can check it that would be of great 
help to me. GetDIBits works good with those parameters selecting a 
stripe of full bitmap.
Now, the second problem on that approach, which emerged testing the same 
autocad part. When blitting *from* screen device, there's no real BMP 
selected onto DC, so the GetDIBits approach is useless. The only way to 
cope with the problem is to make a (third) intermediate conversion, so
DEVICE DC ---bitblt (X11 side)--->memory DC (DDB)---GetDIBits---> DIB
That means 3 data transfers to make a BitBlt operation from display to a 
DIB destination bitmap....
Anyways, even with those bottlenecks, autocad application shows great 
speed improvements on TT fonts (from unusable to about the same windows 
xp speed) with no visible slow downs.

Ciao

Max