WineD3D surface management cleanup

[Stefan Dösinger]

Am Sonntag, 23. September 2007 01:29:32 schrieb H. Verbeet:
> The general direction of the patches seems ok, although I'm not sure
> if RequestLocation / ModifyLocation is optimal from a naming point of
> view. (Ie, RequestLocation typically moves data rather than returning
> a location for the caller to read/write to, while ModifyLocation just
> flips a flag rather than modifying the location of the actual data)
Does LoadLocation sound better? I'm open to suggestions :-)

> OT(?): Wrt. regressions, I would like to mention that I think that in
> general more care should be taken to verify a patch is correct when
> *writing* the patch. I do sometimes get the feeling that the general
> approach taken is one of "Throw some patches at it, see what sticks"
I admit that sometimes I am toying with the "see what sticks" approach, 
especially if I do not have access to the application the issue is about(e.g. 
Pirates! with the alpha fix in unlockrect). Otherwise I'm doing my best to 
make sure that the patch is correct when writing it, and often I write a 
regression test for it too. However, some areas are a bit too complex to 
proove that a patch is correct. Like in the surface code, where we have the 
interactions of FBOs, PBOs, apple_client_storage, various known driver bugs, 
surface conversion, performance considerations, etc(*). It's plainly 
impossible to make sure there are no regressions. So my "there will be tons 
of regressions" note was meant as a "I think the patches are correct, but I 
feel uncomfortable to send them in without testing" rather than "I have no 
idea if that works".

FWIW, I have found only one problem so far, an issue in Battlefield 1942, 
which interestingly shows up in my Vista installation too. Usually our 
continuously growing test suit does a good job in catching most problems.

(*): Before someone(ohsix ;-) ) suggests to use DDI with its perfectly defined 
resource management: Feel free to suggest a redesign that abstracts all 
this(including the driver bugs), I'd be thankful for one. But please describe 
it in your own words, a link to the DDI docs doesn't count(there are license 
issues too, propably).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070924/7aaf0bee/attachment.pgp