Hi,
I have my DIB driver code available on a public git host now: http://repo.or.cz/w/wine/dibdrv.git
I'm going to briefly describe it.
The dib driver (or engine) is a gdi driver. It is loaded into a dc when an application selects a dib, and overrides the existing driver. The magic takes place in SelectBitmap. Safe interaction is provided in gdi32 in four patches. If the winedib.drv.so library is available, then gdi will use the dib driver for drawing into the selected dib. If winedib.drv.so is not available, then gdi will continue using winex11 for example just as before. So these four patches can be safely integrated with the main tree if that is decided to be done.
The rest of the code is the driver itself. It can handle all the standard uncompressed dib formats. It can convert between formats, and it can Get/SetDIBits/Blt. Get/SetPixel is implemented too. No other drawing code is done yet, so only simple GDI apps work. I've tested several apps and I'll list my results.
notepad -- no regressions found winefile -- visual artifacts, but usable bmp loading -- works fine for what has been tested pixel setting -- works fine for every supported format opengl app -- Tribes 1 -- no regressions found d3d app -- Star Wars Battlefront -- no regressions found ddraw app -- Diablo shareware -- no regressions found ddraw app -- Diablo prerelease -- discovered one visual artifact
These are the deficiencies in current code (non-stubs):
No RLE support Missing raster operations in *Blt Get/SetDIBits does not conform exactly yet Bottom-up DIB's not tested for (and probably broken) DIB_PAL_COLORS not tested for No stretching No forwarding calls back to original driver*
*For forwarding back the calls, what I think can be done is use the hbitmap handle originally given, convert it to a DDB, select it, and make the same gdi call again which will then go to the actual device. I do probably need to make sure the dibdrv's physdev persists and doesn't get deleted during this ;) (probably something in Create/Delete DC)
Performance
Originally I was going to state not to expect there really to be any performance improvements. I feel that there are optimizations possible that I have not done, but I left room for. My first concern was correct pixel by pixel operation. So I thought not to expect anything but last night I discovered this, so I might as well share. I have written a program that performs Get/SetPixel to test the various formats. There are 13 total tests, and the program produces 52 MB of output. Just for fun I ran my program without the dib driver and found it took a very long time (I was thinking it hung up at first since it took so long!): timed with winex11.drv real 0m53.903s user 0m19.807s sys 0m5.869s
So I tried it with my driver: timed with winedib.drv real 0m3.924s user 0m3.537s sys 0m0.191s
Indeed, my tests show that there is a 50 second difference with GDI Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Still, I wouldn't expect *your* app to seem much different (or work at all :P)
So will all the interested parties take a look at the driver and I'd sure appreciate feedback on the direction this is going, so we move towards finishing this project beyond the summer of code. :)
Jesse