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:
http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html
Especially see:
http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html
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.