WineD3D: Allocate the resources with VirtualAlloc
stefan at codeweavers.com
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
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
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060419/ddd54f98/attachment.pgp
More information about the wine-devel