Some thoughts about the ominous DIB Engine
stefandoesinger at gmx.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
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070210/f038ff8c/attachment.pgp
More information about the wine-devel