Hello,
looking at the web page:
http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-potential-patch-td19907752.html
I read that there are problems with the ref count in d3d wine implementation.
Does there exist any plan to fix it? Or can we try to implement the Jim's idea
Am Sonntag, 5. April 2009 11:32:38 schrieb paulo lesgaz:
Hello,
looking at the web page:
http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-p
otential-patch-td19907752.html
I read that there are problems with the ref count in d3d wine
implementation.
Does there
It's also affecting one of my bugs:
http://bugs.winehq.org/show_bug.cgi?id=15858
It's sort of random when a real crash occurs but the debugging revealed
that the object that is used was already freed by wined3d.
I can increase the probability of a crash by running a bunch of
memory-hungry apps
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is referenced in any stateblock, even the non-primary ones.
2009/4/5 Stefan Dösinger ste...@codeweavers.com:
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is
Am Sonntag, 5. April 2009 23:59:01 schrieb Henri Verbeet:
I don't know what was discussed on IRC, but essentially we need to
keep track of which resources (in a broad way, not just objects
derived from IWineD3DResource) are in use by a stateblock in wined3d,
and delay destroying the d3d9
2009/4/6 Stefan Dösinger ste...@codeweavers.com:
That was my suggestion. We already keep a wined3d-internal refcount for all
these objects(shaders, textures, ...), and my plan was a callback
function(maybe provided via a COM interface, similar to the
WineD3DDeviceParent one). Some time ago I
