Am Dienstag 28 November 2006 13:18 schrieben Sie: > Stefan Dösinger wrote: > > Am Dienstag 28 November 2006 00:48 schrieb H. Verbeet: > >> I thought we discussed on IRC why this is a bad idea? Anyway, you > >> can't do this. Removing the AddRef in QueryInterface is a pretty > >> blatant violation of COM specs, and is pretty sure to cause problems > >> somewhere. The caller of that function won't always know if the object > >> it's called on is a wined3d object or not, and will depend on the > >> behaviour of QueryInterface as defined by COM. Another thing is that > >> know we get a situation where wined3d objects behave differently from > >> all other COM objects. > >> > >> Also, if, as you stated earlier, the idea of these patches is *not* to > >> get rid of COM in wined3d, I think they're a bad idea. Because in that > >> case all it will do is make wined3d violate COM rules. > > > > I think we should stick to the COM refcounting rules in IUnknown methods > > in wined3d, but drop the d3d specific refcounting. d3d refcounting is > > broken in my opinion, and inconsistent over different versions. So I > > think we should addref in QueryInterface(COM requires this), GetParent(We > > don't addref a wined3d object), but not in d3d methods as SetTexture or > > GetTexture. > > This sounds good to me. Note that if the there is a performance problem > with AddRef'ing and Release'ing objects all the time then the objects > should try to be cached in the object they're being used from. Yeah, we do that, and I don't think the addrefing is a performance issue. oprofile reports the cpu time spent in the various addrefs around 0.001%. But the directx refcounting is hell(dlls/ddraw/tests/refcount.c for example)
pgp2DqwoU0ffa.pgp
Description: PGP signature