DIB Engine & GSoC

[Rolf Kalbermatter]

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