Stefan Dösinger stefan@codeweavers.com writes:
This patch allocates the memory of Surfaces, Indexbuffers and Vertexbuffers with VirtualAlloc instead of HeapAlloc. This will be needed for GetDC to work. It is done for Index- and Vertexbuffers too because they are also managed by the WineD3D resource manager.
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.
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 proposal.
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 :-)
Stefan
-
Alexandre Julliard -
Stefan Dösinger