Hi Allen,
Allen Bierbaum wrote:
>
> This still worries me.
>
> What amount of overhead does it introduce? Are we talking a table
> lookup and indirection or is it something heavier than this? I could
> see this being too much overhead for the internals of OpenSG, but at the
> user level it seems to me that this would be fine 95% of the time and
> then users that know they have an issue could just get a reference to
> the cptr from the MTRefPtr (much like they would even with RefPtr's) and
> use that for the performance critical parts of their code.
Right now it's a vector lookup, and I don't see why it would be more.
> As far as most applications not using it, I agree. But I see that as a
> problem to be fixed. Please take this as constructive criticism, but
> IMHO, the fact that there are not many good multi-threaded examples and
> that there is not an easy way to enable APPCULL_DRAW style separation
> right now is why not many apps use them. This a bit of a pity since one
> of the largest selling points of OpenSG is that it has such nice support
> for multi-threading but yet as you say "not many applications use it".
> I would personally like to see that change now that we are all in a
> multi-core world where OpenSG could really shine.
True.
> Back to MTRefPtr's though...
>
> Are there default constructors to convert from RefPtr to MTRefPtr? For
> example could I just use an MTRefPtr in my application everywhere that I
> would use a RefPtr (including CoredNodePtr's)?
MTRefPtrs are not implemented yet, due to uncertainty about how to handle
cross-aspect refcounts. Carsten and I talked about it and think we know how to
do it, but AFAIK he's still working on the implementation.
Otherwise, yes. For the CNPs we would have to provide new classes, but that
would be a goal.
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
