[PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

[Stefan Dösinger]

On Monday 31 October 2011 21:06:09 Henri Verbeet wrote:
> Probably in general. The way GetDC is supposed to work is probably by
> asking the graphics driver to create a DC on top of the existing
> memory or texture, instead of the DIB section hacks we do in wined3d.
In the days of the old ddraw code we used to have a Wine-specific export in 
gdi32 that did that, but I don't think adding that back 1:1 is a good 
solution.

We could allocate surface memory in ddraw and copy between that and the memory 
wined3d's map() returns for some or all surfaces. This would deal with cases 
where an app(Some Windows Media Player 9 visualization plugins specifically) 
use SetSurfaceDesc to set lpSurface and then call GetDC, and we could get rid 
of SFLAG_USERPTR in wined3d. It would also be more reliable for the backbuffer 
than hoping the memory returned by glMapBuffer remains valid.

Alternatively we could make the dibsection a separate location, but that 
wouldn't deal with apps that want the backbuffer memory to stay the same.

> and since
> OWNDC implies the application wants to keep the DC around anyway, we
> might as well set it up at surface initialization.
This is probably correct, but do you have docs for OWNDC, besides of the name 
and very short description in msdn/sdk?

I don't think IE8 sets OWNDC here, this is most likely our ddrawex.dll. And 
the main reason I've set it there is because it kinda-sorta sounds like what 
the ddrawex DDSCAPS_VIDEOMEMORY | DDSCAPS_SYSTEMMEM hack is doing, not because 
I had any in-depth information what OWNDC does, so I'd be wary about reading 
too much into it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20111031/7d462d09/attachment.pgp>