DIB Driver code available

[Stefan Dösinger]

Am Donnerstag, 23. August 2007 20:59 schrieb Jesse Allen:

> > While you're at it, can you make it more universal so we can add a
> > wined3d driver too, and convince AJ about it?
>
> Okay, but the dib driver is special. A dib works on any device, so
> that's why I can convert between. You're not supposed to blit across
> different devices. Could you point out your issues with blitting and
> wined3d?
Applications are supposed to be able to blit between d3d DCs and "normal" 
DCs(DIBs mostly). This works currently because wined3d downloads the gl data 
into a DIB and passes a DC of that DIB to the app. I wanted to improve our 
performance of GetDC on render targets by writing my own GDI driver, and 
return a DC whose functions draw directly in opengl, rather than downloading 
and reuploading.

Nice plan, with one exception: Now I have made d3d surfaces a different 
device, which they are not supposed to be. Cross-Device blits aren't supposed 
to work, d3d<->dib blits are. Or are Device Independent Bitmaps a different 
matter here? I do not think so, as I understand them they belong to the 
general windowing device class.

Alexandre says that my opengl driver should go into winex11, and he's right 
with that. On Windows <= XP, d3d is part of gdi, thus the d3d implementation 
is part of the gdi driver. I am not sure about Vista, but I think they 
removed it from gdi there to simplify the drivers. Now I do not like the idea 
of moving wined3d into winex11 or gdi32 altogether, so I'd have to split out 
the opengl gdi parts.

Now the trouble is, that doesn't work. WineD3D manages the opengl contexts, 
and the gdi calls would need a context, and specific states set up. This 
could be fixed by writing a wine-private gl extension to get a hdc on the 
back buffer, which offers the driver implementation a callback to request a 
context from the user of the extension(wined3d). Also not a really nice 
solution.

Another way suggested by Chris was to create GLXPixmaps, copy the back buffer 
into it, and then have gdi draw on it, then copy them back. The X server can 
optimize this, and keep the copying and drawing GPU-Side. However, that way 
we depend on the mercy of X11 and the driver to be able to do the xlib calls 
on the gpu. I doubt that they do it, but I'll play with this approach a bit 
more.

The only gdi function I am really interested in is ExtTextOut, and perhaps 
GetDIBBits. Some games use it to draw text on the back buffer, and they're 
terribly slow(down to 0.5 fps). I have started a proove of concept 
implementation[1] which suffered from the Cross-Device BitBlt 
problem(theoretically, and pop3d used it, but apparently without doing 
anything with the results).

I do not see any essential difference between your DIB driver and a wined3d 
driver from the BitBlt point of view.

http://www.winehq.org/pipermail/wine-devel/2007-May/057170.html