OpenGL-Accelerated DirectDraw: Experiances and expectations

Stefan Dösinger stefan at codeweavers.com
Sun May 7 04:23:38 CDT 2006


Am Samstag, 6. Mai 2006 19:57 schrieb Joseph Garvin:
> Stefan Dösinger wrote:
> > One of these nasty things is GetDC on the render target. Age of Empires 2
> > and Settlers 3 to that to draw text. This is going to be unplayably slow
> > I'm afraid. Wine will need a dib engine for that to work.
>
> I'm a bit unfamiliar with win32 but I know opengl; what exactly is
> happening in this case? Does this cause it to revert to GDI for font
> drawing or ... ?
When GetDC is called, the surface has to be copied into a dib section in main 
memory, then a dc is created for it. On UnlockRect, the contents of the dib 
section are written back to gl.

For rendertargets this means that the front / back buffer has to be read with 
glReadPixels, and later written back with glDrawPixels or by drawing a 
textured quad.

Without a dib enginethe basic GetDC problem applies: The surface has to be 
converted into the X servers color depth, and copied into a server side 
bitmap. After the drawing operations, it is copied back to be uploaded to gl.

> > Swat3 showed another problem: It renders the main menu, mouse pointer and
> > the in-game hud with ddraw blts, which works just great basically. In
> > opengl the main menu renders at ~500 fps, instead of ~40 fps with the old
> > gdi code. But whenever I move the mouse pointer over a control, it starts
> > locking all it's surfaces in read-write mode, which requires them to be
> > reloaded to gl and takes performance down(2-3 fps). This is made worse by
> > the surface convertion for color keying emulation.
>
> Why does the locking require reuploading the texture? Have you tried
> always having textures uploaded the way you do for read-write surfaces?
> The performance hit may be small.
When the texture is locked read-write by the app, it is marked dirty, and the 
next time it is used, the opengl texture is updated. Texture uploads take 
some time, and usually they are done only once while the game loads. However, 
swat3 locks the surfaces it uses for blts on every frame, but without 
changing anything.

This does not only require a glTexSubImage for each texture modification, I 
also have to do some texture conversion to emulate color keying(convert the 
565 rgb texture to a 1555 argb texture).

> > I expect opengl-accelerated directdraw to take some more time, and there
> > will be some games(GetDC) which are unlikely to work well at all. I will
> > make some modifications to the WineD3D texture loading code to only
> > upload changed areas, which should improve the problems a bit.
>
> How are you planning to do that without keeping the texture in memory
> after it's loaded into the card?
I will keep some counters in the surface, counting
* How often the surface is locked
* How often the surface is actually changed
The memory of a surface that isn't locked often(e.g. less than 5 times), the 
surface memory can be freed. If it is locked more often, the memory won't be 
freed, so the time spent for reading the opengl surface back is saved. To 
find out if a surface is really changed, I can eighter keep a copy of the old 
content around, or use some hashing method. A hash or memcmp will take time 
too, so if it turns out that the surface is locked very often without beeing 
changed, comparing the the surface can be skipped and the surface isn't 
uploaded. Of course sometimes it has to be checked, just in case it's 
somewhen really modified. On the other hand, if the surface is changed on 
every lock, the comparison can be skipped too and the new surface is just 
oploaded to gl.

I have an quick and dirty implementation of that, and it seems to work fine. 
The swat3 main menu is faster by a factor of 100(100-500 fps instead of 1-5) 
when swat3 does extensive surface locking. The videotex sdk demo is approx. 
130 fps faster(940 instead of 810). It hits the case where the surface is 
locked often enought to be marked clean without beeing checked 5-6 times, and 
on the next check it turns out that it was modified. The movie in the cube 
still plays fine, the only negative effect is a slight delay before the 
texture update is recognised(well, when it's running at 940 fps a delay of 5 
frames shouldn't be a problem.

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/20060507/afb47be1/attachment.pgp


More information about the wine-devel mailing list