WineD3D surface management cleanup
Stefan Dösinger
stefandoesinger at gmx.at
Sun Sep 23 17:51:40 CDT 2007
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
More information about the wine-devel
mailing list