Damjan Jovanovic [mailto:damjan.jov@gmail.com] wrote:
There are probably several ways to do a DIB engine.
The way I would do it, is the way that Transgaming did it in that patch a
number
of years back, ie. where wine does:
Actually better would be IMO to place it all in GDI. A lot of the Eng.. API functions that win32k.sys exports (which is basically just the GDI engine put into the kernel Space, and GDI32.DLL exports them actually too by forwarding to win32k.sys) deal with just this stuff among other things. Basically a W2K display driver can hook certain DIB operations to do itself and in case he only implements certain features such as bit depths he can forward the rest to those Eng.. functions too. If a driver did not hook the particular DIB operation (or maybe even if it failed it) win32k.sys will also call this Eng.. functions.
The problem I see with this is that implementing those Eng.. Functions that are documented in the DDK would make most sense by using the same prototypes but this Eng.. API is much more modelled around the w2k display driver interface that has by far not the direct 1:1 function mapping to the actual GDI functions as what the Wine display driver currently uses. Even the functions that are functionally similar use quite different parameter types.
But I asked Alexandre about this, and he said the whole point of the DIB
engine is
that you shouldn't need the locking. How that would work is beyond me,
after all,
if you only draw on the client-side, you still have to upload the image to
the X server
when you want it to become visible, but what about images that aren't
double-buffered,
and what about mixed drawing with OpenGL?
The idea is that once DIBs are entirely handled in the DIB engine, no locking is required anymore. Basically locking (and synchronization) is necessary since a DIB can be either handled through GDI functions or through direct memory access through its bitmap pointer. So for direct memory access whenever the DIB is in server mode it needs to be converted back to local mode before allowing access to the memory and when a display driver function is called to operate on a DIB the opposite needs to be done.
The only synchronisation for DIBs when having a fully working DIB engine would be when the DIB is blitted to the display. There is possibly a complication with OpenGL and Direct3D here but I'm not sure about the details for that.
Ge van Geldorp [ge@gse.nl] wrote:
I was actually quite proud of that code generator and the code it produced. The DIB code generator is absolutely clean, MS doesn't ship anything like
it
so it's simply impossible that it was created using reverse engineering. I
put
the code generator under the LGPL, specifically so it could be used by Wine if so desired. Note that the scope of this is limited to BitBlt's though,
it
won't help when you need to draw a 3-pixel wide dash-dotted ellips on your DIB surface...
Thanks Ge for this lengthy and good explanation. As to the drawing optimization I don't think that is a real trouble, certainly not to start with. Wine wants first something working correct and then one can decide if some fancy optimization for (dashed) lines, ellipses etc are at its place.
Rolf Kalbermatter