Wine staging tree

Mon Oct 6 05:46:37 CDT 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-10-06 12:06, schrieb Henri Verbeet:
> There's of course no reason you can't test your own code without a 
> staging tree. And quite frankly, almost all the work I did on the 
> command stream without a staging tree is upstream, and very little
> of yours is.
I stopped working on upstreaming the command stream after you made a
d3d10/11-like resource interface the de-facto requirement for merging
location management in a (sub-) resource class
(https://www.winehq.org/pipermail/wine-patches/2013-October/127312.html,
and later on a series that introduced a subresource class in the wrong
way). I worked on moving away some surface and volume methods as time
permitted but gave up on upstreaming the CS until you're done with
d3d10/d2d.

The same concern regarding resource structures would apply to
694cdcc41cc74eff8c1d96ac0e18895862b22476 and the draw_binding
counterpart in my eyes. Maybe it's time to re-visit merging location
management in the resource class without first eliminating surfaces
and volumes entirely after I'm done with the focus loss work?
(Otherwise I'll go on moving away more calls to surfaces and volumes.)