WineD3D: Allocate the resources with VirtualAlloc

Stefan Dösinger stefan at
Wed Apr 19 10:40:17 CDT 2006

Am Mittwoch, 19. April 2006 11:15 schrieben Sie:
> I'm not sure I agree with that. Are you planning to trap accesses like
> the DIB code does?  That sucks pretty badly in the DIB code, I don't
> think we want to do any more of that.
Actually, I plan to create a DIB section on demand on this memory(when GetDC 
is called), like ddraw does at the moment. For a propably better way to do 
GetDC on opengl textures, I've just written an answer to the dib engine 

I'm also looking at trap accesses for locking opengl surfaces. I have done 
some performance tests with glDrawPixels, glReadPixels and glTexSubImage2D, 
and they are horribly slow. We can be lucky if glDrawPixels archieves 25fps 
on writing to a 1024x768 render target.

There are some apps which lock the whole render target to draw a few things 
like a HUD and a crosshair on the screen, so we are transfering the whole 
render target from the card and back to the card just to change about 10% of 
the screen.

To speed that up I'd like to use trap accesses to find out which parts are 
changed and to avoid unecessarily reading the whole target back from gl. 
(glReadPixels is the fastest for that, and it is 50% slower than 
glDrawPixels). Ohsix told me on #winehackers that windows handles surface 
locking this way. I haven't verified that, can you comment on this ohsix?

I'm also open to suggestions if one knows a better way to do this :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url :

More information about the wine-devel mailing list