SOC: Integrate DIB Engine

[Stefan Dösinger]

Hi,
> One thing I'd like to try to work on is the DIB engine. Do we need
> someone to work on it still? This one is also interesting to me
> because we have some documentation already and that I have worked with
> bitmaps before too. I'd also like to find out how this stuff might
> integrate with the current changes going into ddraw.
>
> http://www.winehq.org/?page=fun_projects
> GDI Engine
For DirectX games, such as Age of Empires 2, I propably have an OpenGL-ish 
solution for the problem. I haven't looked at it in detail, so no promises 
that it is possible at all, but this was my idea:

Basically, DirectDraw apps do the following things with surfaces:
*Locking
*Blits
*GetDC

Basically there are two surface types: Render targets and offscreen surfaces. 
In the general case, locking is only done for offscreen surfaces, and 
basically during loading time, or when a surface has to be updated. In the 
current ddraw code, Blits are done in software, and they involve locking both 
surfaces. GetDC also holds a lock on the surface, which is essentially a dib 
section, and then doing the usual gdi stuff.

With opengl, the situation is a bit changed: Locking the surface requires 
transfering the data from and to video memory with glTexSubImage, 
glDrawPixels and friends. This is quite slow for full surfaces, but it 
usually occurs at loading time only. If some apps are bad-behaved and do a 
full lock of the rendertarget, this has a big performance impact at the 
moment, but this can be optimized a lot. Blits can be handled in hardware 
with 3D drawing, so they should work nice and fast :-)

The remaining problem is GetDC. At the moment this requires copying the 
complete surface from opengl to main memory, converting it to the servers bit 
depth, and copying it to a server-side pixmap. Here the new 
texture-from-pixmap glx extension can help. It should allow us to link the 
opengl texture directly to the pixmap gdi works on, without the need to copy 
it through wined3d. This extension is beeing designed for the new aiglx (and 
xgl?) stuff, so we can expect driver support soon, and the x server/opengl 
driver can optimize the image transfer nicely.

Well, what problems occur: The extension is not finished yet, we have to wait 
for this first. It's also not clear to me if the image transfer is supported 
in both ways, from pixmap to texture and from texture to pixmap. Furthermore, 
the textures should be in the server's color depth. For palettized surfaces, 
the conversion can be done when the game loads the surfaces, which is at the 
game loading time, if it is well-behaved. WineD3D already does that, if the 
card doesn't support palettized gl textures(most modern cards do not support 
that)

That's my basic idea, I haven't done any deeper investigation if that is 
possible at all, so I might be woken up from my daydreams now :-D

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060419/8b36d3fa/attachment.pgp