[PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

[Stefan Dösinger]

Am Sonntag, 27. November 2011, 17:02:01 schrieb Henri Verbeet:
> I'm not entirely sure that we shouldn't just use either
> EXT_texture_snorm or the NV_texture_shader formats and mark the
> formats as unsupported otherwise though.
That's not an option. My iMac doesn't support either extension(r500, up to 
date Lion) and EXT_texture_snorm doesn't support 
WINED3DFMT_R5G5_SNORM_L6_UNORM.

> Not yet. I came across this while investigating how we should handle
> P8 primary surfaces for ddraw. You'd have a RGBA8 frontbuffer in
> wined3d and a P8 surface in ddraw.
This would elimintate the need to have P8 surfaces that are ALPHA8 in the gl 
texture and RGBA8 onscreen. However, which implications does that have for the 
ddraw shadow frontbuffer in the long run?

I'm asking because of overlays and, to some extend, the software d3d8/d3d9 
cursor. For those I need a shadow frontbuffer in wined3d. If ddraw keeps using 
one as well we might end up with a pretty long blitting chain and redundant 
code.

To fix some issues with overlays(tearing, moving the overlay) I have to 
composit the primary and overlay in the wgl backbuffer and then call swapbuffers 
to have a vsynced present. (This need some more tests, especially the vsync 
timing).

The d3d8/9 software cursor behaves pretty similarly to a ddraw overlay. It can 
be moved without a present call and doesn't leave behind an old cursor image. 
It doesn't show up in the backbuffer after a D3DSWAPEFFECT_FLIP blit. It does 
however show up in GetFrontbufferData. Printscreen copies the backbuffer 
contents to the clipboard, so I can't test if the SW cursor shows up in 
regular screenshot.

(Note that ddraw overlays are currently broken because ddraw's UpdateOverlay 
uses the wrong wined3d surface. That is not hard to fix, but even then no app 
would use overlays because our caps are broken)
-------------- 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/20111127/1e2e92e9/attachment.pgp>