Closed GoogleCodeExporter closed 9 years ago
After debugging some more I think the problem is even worse.
I took a closer look at "ComObject::Destruct()", as ComObject is used for all DX
resources.
It's here:
m_Unknown->Release();
m_Unknown = NULL;
After releasing my first reference, m_Unknown is set to NULL. But as it's
pointing to
the same ComObject as my second reference, m_Unknown is also NULL there.
I understand you need to lookup the objects in the ObjectTable to always
provide the
same managed wrapper object for the same unmanaged DX object. The only solution
I see
at the moment is doing "your own" refcounting in the ComObject class.
A solution might be (in pseudocode):
m_Unknown->Release();
if(m_Unknown.IsFreedBecauseRefCountIsZero())
m_Unknown = NULL;
I hope you can understand the problem as I explained it here, english is not my
native language...
Refcounting has always been a nightmare to deal with, that's why I don't like
COM :)
Original comment by michael.stoyke@gmx.de
on 26 Oct 2008 at 4:31
Dispose() does not "decrease the reference count" -- rather, while the code
path may
call Release(), that's an implementation detail and not the documented
behavior.
Dispose() is what you do to an object you created (with "new") when you are no
longer using it.
You should only Dispose() what you explicitly create, so the fact that you are
Dispose()ing the result of GetBackBuffer() is an error. If you have a case
where
omitting the Dispose() call creates a problem, then that is a bug and you
should
file a seperate bug report with the details.
See these blog entries for more detail:
http://scientificninja.com/development/com-and-slimdx-part-i
http://scientificninja.com/development/com-and-slimdx-part-ii
Original comment by josh.petrie
on 26 Oct 2008 at 4:54
Thanks for pointing me to the blog, I should've known about that earlier, would
have
stopped me from writing this "bug report" :)
Now I understand the design decisions for refcounters in SlimDX. After thinking
about
it for some time I think the way you do it is much better than the "DirectX
way".
I'll change my code and want to check if I'm still experiencing leaked
resources,
like I did before using Dispose everywhere.
If there are more online resources about SlimDX besides the wiki and the blog,
I'd
like to kindly ask you to send me the links (my username is also my email
address).
I'm sorry for giving you guys so much trouble today, but I just started using
SlimDX
yesterday and it looked to me like "just a plain 1:1 wrapper of DirectX for
.NET".
I'm usually not rushing into using a "new" library that I have little knowledge
about, but I want to convince our team of using SlimDX instead of MDX for our
next
project. The only way to achieve this is to have something up and running by
monday :)
Original comment by michael.stoyke@gmx.de
on 26 Oct 2008 at 5:54
The next version of the documentation that I'm working on tries to call a lot
of
this stuff out, rather than just being a plain class reference. I'm aiming to
have
the preliminary version of that finished for the November release, so hopefully
this
sort of thing will be more clear than it has in the past. I realize that right
now
things are very much not ideal.
Original comment by promit....@gmail.com
on 26 Oct 2008 at 1:36
Original issue reported on code.google.com by
michael.stoyke@gmx.de
on 26 Oct 2008 at 3:48