Robert,
I thought I'd ping this email... the change is very small and should be easy
to know right away if it is safe or not.

----- Original Message ----- 
From: "James Killian" <[email protected]>
To: "OpenSceneGraph Submissions" <[email protected]>
Sent: Monday, March 23, 2009 10:28 PM
Subject: Re: [osg-submissions] Text3D fix



Ok here is something that should work.  This was built with 9943 (since I
couldn't use 9944).
I've tested with our game and now the cache is properly populating once
again.  :)


James Killian
  ----- Original Message ----- 
  From: Robert Osfield
  To: OpenSceneGraph Submissions
  Sent: Monday, March 23, 2009 9:07 AM
  Subject: Re: [osg-submissions] Text3D fix


  Hi James,

  You are welcome to dive and look a full solution.  Exactly what this might
look like I can't say right now, my hunch is that we'll need to refactor the
cache management such as making it state of ReaderWriter::Options object.
If you don't feel comfortable with having a bash then you'll need to wait
for me to have a free slot in which to tackle it.

  Robert.


  On Mon, Mar 23, 2009 at 1:58 PM, James Killian <[email protected]>
wrote:


    Robert,
    Is there enough information in the previous email to know what direction
I
    wanted to address this issue?

    If you want I can make the fixes and submit it... Ideally I'd like to
know
    if this sounds like it should work or if you wanted to pursue managing
the
    cache differently (i.e. attached to the ReaderWriter::Options object).

    Please let me know when you have a chance... Thanks.



    ----- Original Message -----
    From: "James Killian" <[email protected]>
    To: "OpenSceneGraph Submissions"
<[email protected]>

    Sent: Thursday, March 19, 2009 1:44 PM
    Subject: Re: [osg-submissions] Text3D fix


    > Is the read implementation's useObjectCache = false suppose to
override
    all
    > cache hints that were provided by the options?  I'm assuming not but
just
    > the cache hint of that type... if so...
    >
    > Seems like instead of passing a bool we could be passing the
    > CacheHintOptions type and do an if with that against the
    readFunctor.options
    > something like:
    >
    > readImplementation (readFunctor, CacheHintType)
    > {
    >     bool useObjectCache= readfunctor._options->getObjectCacheHint() &
    > CacheHintType;
    >     if (useObjectCache)
    >     {
    >     }
    >     else
    >     {
    >         read();
    >     }
    > }
    >
    >     That should be thread safe since everything is protected within
the
    > parameters
    > What do you think?
    >
    > On a side note it appears all the derived functor types construct the
bool
    > using cachehints & the type they represent.
    >
    >
    > ----- Original Message -----
    > From: "Robert Osfield" <[email protected]>
    > To: "OpenSceneGraph Submissions"
    <[email protected]>
    > Sent: Thursday, March 19, 2009 11:34 AM
    > Subject: Re: [osg-submissions] Text3D fix
    >
    >
    > > Hi James,
    > >
    > > The swaps are in their to prevent the local object cache from being
    > > populated for the case when useObjectCache is false.
    > >
    > > Reviewing the code now it's clear that the code isn't robust in the
    > presence
    > > of multi-threading.  Removing the local cache and the swaps wouldn't
    solve
    > > anything as it would simple may that the cache is used even when
you've
    > > asked for it not to be used.
    > >
    > > As to solution it's not going to be straight forward, it'll require
the
    > > cache to be managed differently, and most likely attached to the
    > > ReaderWriter::Options object.
    > >
    > > Robert.
    > >
    > > On Thu, Mar 19, 2009 at 2:38 PM, James Killian
    > <[email protected]>wrote:
    > >
    > > > > Behaviours:
    > > > >     Cache management is delegate to osgDB::Registry, but cache
    > > > >     coherence (load a file with option then reuse it, deactivate
the
    > > > >     cache when load a specific file or don't cached the loaded
file)
    > > > >     is user's responsibility.
    > > >
    > > > I actually ran into a similar issue... let me explain here:
    > > >
    > > > Looking at the latest rev 9884 of Registry.cpp around line 1641 in
the
    > > > readImplementation() we see
    > > > else
    > > > {
    > > >    ObjectCache tmpObjectCache
    > > >    swap
    > > >    read
    > > >    swap
    > > >    return
    > > > }
    > > >
    > > > I would dare to submit to remove the swaps, but first ask if they
were
    > > > removed what would be broken as this has been this way for a long
    time.
    > > >
    > > > Stress that breaks _objectCache:
    > > > As of now if I have 2 threads loading where some object types are
    cached
    > > > and
    > > > others are not (e.g. cached images but not nodes)... what happens
is
    > that
    > > > the line 1631 addEntry() adds to the tmpOjectCache, and therefore
the
    > real
    > > > _objectCache never gets populated.  :(
    > > >
    > > > If someone can at least explain why the swaps were added I would
be
    > > > eternally grateful.
    > > >
    > > >
    > > >
    > > > ----- Original Message -----
    > > > From: "David Callu" <[email protected]>
    > > > To: "OpenSceneGraph Submissions"
    > <[email protected]
    > > > >
    > > > Sent: Friday, February 27, 2009 8:47 AM
    > > > Subject: [osg-submissions] Text3D fix
    > > >
    > > >
    > > > > Hi Robert
    > > > >
    > > > > Problem:
    > > > >      osgText::Text and osgText::Text3D use the same font file.
    > > > >      The first really load the file and obtain an osgText::Font
    > object,
    > > > >      the second use the cache created during the first load of
the
    > > > >      font file, and so obtain an osgText::Font object instead of
    > > > >      osgText::Font3D object. To obtain an osgText::Font3D
object,
    > > > >      osgText::Text3D call osgDB::readObjectFile(...) with an
option
    > > > >      to specify the plugin we want an osgText::Font3D instead of
    > > > >      osgText::Font.
    > > > >
    > > > > Generalised Problem:
    > > > >     In osgDB::Registry, loaded file cache is referenced by the
name
    > > > >     of this file, so if I load a file with some options, and the
    cache
    > > > >     already contain object for this filename, I obtain an object
    > > > >     potentially not loaded with my options.
    > > > >
    > > > > Behaviours:
    > > > >     Cache management is delegate to osgDB::Registry, but cache
    > > > >     coherence (load a file with option then reuse it, deactivate
the
    > > > >     cache when load a specific file or don't cached the loaded
file)
    > > > >     is user's responsibility.
    > > > >
    > > > > Text3D solution:
    > > > >     Postfix the font file name by .text3d or something similar
and
    > then
    > > > have
    > > > > the freetype plugin return
    > > > >     osgText::Font3D when it detects this.
    > > > >     This operation is done by osgText::readFont3DFile() which
unsure
    > the
    > > > > filename have .text3d as extension.
    > > > >     This is totaly transparent for user, and backward
compatible.
    > > > >
    > > > >
    > > > > BTW, I fix the bug about the Normal of 3D text. Currently, the
front
    > and
    > > > > wall face have
    > > > > the same normal (0,0,1) in the Text3D object coordinate. Now the
    wall
    > > > face
    > > > > have its own
    > > > > normal array computed by the plugin.
    > > > >
    > > > > BTW 2, I implement
    > > > > - void Text3D::accept(osg::Drawable::ConstAttributeFunctor& af)
    const
    > > > > - void Text3D::accept(osg::PrimitiveFunctor& pf) const
    > > > > so now statistics are well reported.
    > > > >
    > > > > I join modified file in osgText3D.tgz and a the original test in
    > > > > testText3D.tgz
    > > > >
    > > > > Cheers
    > > > > David Callu
    > > > >
    > > >
    > > >
    > > >
    > >
    >




> --------------------------------------------------------------------------
    > --
    > > > ----
    > > >
    > > >
    > > > > _______________________________________________
    > > > > osg-submissions mailing list
    > > > > [email protected]
    > > > >
    > > >
    > > >
    >

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
    > > > >
    > > >
    > > > _______________________________________________
    > > > osg-submissions mailing list
    > > > [email protected]
    > > >
    > > >
    >

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
    > > >
    > >
    >
    >




> --------------------------------------------------------------------------
    --
    > ----
    >
    >
    > > _______________________________________________
    > > osg-submissions mailing list
    > > [email protected]
    > >
    >

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
    > >
    >
    > _______________________________________________
    > osg-submissions mailing list
    > [email protected]
    >

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
    >

    _______________________________________________
    osg-submissions mailing list
    [email protected]

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org





----------------------------------------------------------------------------
--


  _______________________________________________
  osg-submissions mailing list
  [email protected]

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org



----------------------------------------------------------------------------
----


> _______________________________________________
> osg-submissions mailing list
> [email protected]
>
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>

_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to