SOC: Integrate DIB Engine
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 Integrate the GDI engine contributed by the TransGaming folks. * workers: wanted * status: to do * updated: June 24, 2005 Jesse
On Wednesday 19 April 2006 08:46, Jesse Allen wrote:
One thing I'd like to try to work on is the DIB engine. Do we need someone to work on it still?
Yes. See <http://wiki.winehq.org/DIBEngine> for more information on this. This is probably feasible as a SOC project *if* you are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it. -- Troy Rollo - wine(a)troy.rollo.name
Troy Rollo wrote:
Yes. See <http://wiki.winehq.org/DIBEngine> for more information on this.
This is probably feasible as a SOC project *if* you are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it.
Alexandre has very specific ideas about how he wants a DIB Engine done. Integrating a DIB engine into your own tree may not be too difficult. The hard part is integrating it into the Wine tree in small pieces without breaking everything else and keeping Alexandre happy as you go. Mike
Mike McCormack wrote:
Troy Rollo wrote:
Yes. See <http://wiki.winehq.org/DIBEngine> for more information on this.
This is probably feasible as a SOC project *if* you are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it.
Alexandre has very specific ideas about how he wants a DIB Engine done.
Good! We already have the mentor for this task then ;)
Integrating a DIB engine into your own tree may not be too difficult. The hard part is integrating it into the Wine tree in small pieces without breaking everything else and keeping Alexandre happy as you go.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
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
On 4/19/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
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
Yeah that sounds like a great idea, but likely after the SOC, because as you say the extension is not ready. My main goal is to get DIB out of X and into our own code. I wanted to get the message out that I want to look into doing this before I stepped on anyones toes. Jesse
participants (5)
-
Jesse Allen -
Michael Stefaniuc -
Mike McCormack -
Stefan Dösinger -
Troy Rollo