Dirk Reiners wrote: > 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.
Based on your answers, I guess I don't see why the user-level Ptr shouldn't just be a MTRefPtr. What do you think? -Allen ------------------------------------------------------------------------- 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
