DIB Driver code available

Jesse Allen the3dfxdude at gmail.com
Thu Aug 23 11:58:11 CDT 2007


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



More information about the wine-devel mailing list