DIB Engine, some summarization

[Rolf Kalbermatter]

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
important.
Or is it the idea to use the DIB engine for device dependant bitmaps
attached
to the device context too? Because that would make at least this case
probably
indeed more complicated.

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

DIBs however have the additional problem of using any possible bit depth
with
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
acceleration
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
solves
the problems with X11 not supporting arbitrary bit depths and also
synchronisation
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
for
DIBs if he wants. If he does he would of course have to make sure all bit
depths
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
device
bitmap in the device context too (under Windows a driver doesn't need to do
that,
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