DIB Engine, some summarization

Rolf Kalbermatter r.kalbermatter at hccnet.nl
Tue Feb 13 01:39:20 CST 2007

Damjan Jovanovic [mailto:damjan.jov at gmail.com] well:

>What about the case where you draw with GDI, then render with OpenGL on 
>top of that, then draw on top of that with GDI, then swap buffers?
>If you draw only client-side, you have to copy to the server, then copy 
>back, then copy to the server *again*. You have to upload or download 
>the image *every time* you go between OpenGL and GDI drawing, whereas 
>when you draw with X11, there is no uploads/downloads unless you use 
>DIB sections and draw directly.

Well, I have to admit I don't understand the whole complexity with DirectX,
OpenGL and GDI. But the DIB engine is mostly for DIB sections I would think.
It could be used for most device dependant bitmap surfaces too as long as
the driver puts them in the surface structure of course, since that are just
bitmaps too, but if that would be wise is another question.

I would think that to start with the handling of DIBs would be most
Or is it the idea to use the DIB engine for device dependant bitmaps
to the device context too? Because that would make at least this case
indeed more complicated.

As far as X11 is concerend device dependant bitmaps should not pose a
other than possibly performance if an application also wants to draw
in the bitmap. But this works now and could be left in. And the bit depth
be alright since the ddb should be in the same bit depth as what the X11

DIBs however have the additional problem of using any possible bit depth
X11 only really supporting the currently used bit depth. So here you want to
get X11 out of the loop if possible.

>X11 drawing has some more advantages, like being able to use forms of 
>hardware acceleration (XAA/EXA) that client-side drawing can't.

That might be but arbitrary bit depth support for hardware related
is probably not very common among chip sets.

>A pure client-side drawing strategy is IMO inferior to a strategy where 
>you can draw  client-side or server-side, as the need arises.

I think DIB drawing should be if possible kept on the client side. That
the problems with X11 not supporting arbitrary bit depths and also
of the bitmaps if the application uses direct bitmap access too.

And it wouldn't be pure client side at all. A driver can hook functions even
DIBs if he wants. If he does he would of course have to make sure all bit
are supported and synchronisation is taken care off. Support of all bit
depts would
be quite easy as it could decide to do whatever modes it can do and
otherwise pass
it on to the GDI engine anyhow.

If the driver doesn't hook or fails that function somehow then the GDI
engine is
used to do the operation for the DIB. And at least for drivers having their
bitmap in the device context too (under Windows a driver doesn't need to do
for instance always drawing directly to the shared video memory), it might
be possible
to use the DIB engine too, but that would be the drivers decision and as
said I'm
not yet sure that is how it's done under Windows nor if it should be done
this way.

Rolf Kalbermatter

More information about the wine-devel mailing list