Damjan Jovanovic [mailto:damjan.jov@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