Some thoughts about the ominous DIB Engine

Stefan Dösinger stefandoesinger at
Sat Feb 10 04:11:40 CST 2007

Am Samstag 10 Februar 2007 09:49 schrieb Rolf Kalbermatter:
> Felix Nawothnig wrote:
> >I suggested to do all the work server-side a while back:
> >
> >
> >
> >Especially see:
> >
> >
> Well, this would mostly mirror the Windows architecture nowadays where
> almost all of this is in win32k.sys and GDI32 is mostly a user space
> wrapper around that. A bit like ntdll does for kernel operations.
> But I would be a bit concerned about performance if most calls have to
> be passed to the server side to be handled but maybe that is not really
> an issue? Didn't MS put part of the GDI somehow back in user space when
> going from NT4 to 2K just because of performance concerns?
I think performance could be ok if we use shared memory to get the dibs in and 
out of the server, but I think Alexandre does not like shmmem for the one or 
other reason. Afaik MS had GDI in user space in NT 3.5, but for performance 
reasons they put it into the kernel in 4.0 and win95. But I think for windows 
some considerations regarding hardware acceleration also apply.

If I understand things correctly, performance problems occur if a DIB section 
is switched from server mode to app mode, or vice versa. As long as it stays 
in one or the other mode it is fine. DirectDraw is a much simpler interface 
than GDI. DDraw currently draws mainly in appmod, problems occur if GetDC is 
used on a surface. This could maybe avoided if the ddraw implementation was 
changed to use GDI for blitting too, instead of its own code. However, 
problems will occur if the application Locks the surface. So I think this 
would only shift the problem to other apps, and it would not help Direct3D 
apps, or opengl accelerated DirectDraw.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the wine-devel mailing list