Robert,
Perhaps what we really need is a way to dynamically change the max
number of display lists without incurring the cost of a mutex.
Solution:
class DisplaySettingsListener { public: virtual
displaySettingsChanged() = 0; };
Add std::list<DisplaySettingsListener*> to DisplaySettings
Have buffered_value inherit the DisplaySettingsListener interface
and add itself to the display settings list
Every time setMaxNumContexts() is called it will notify all of the
listeners.
Cost:
One additional pointer for each object that needs notified.
While I believe that there is a way to control the link order of
static variables via build options, my experience has been that it isn't
very reliable or friendly to 3rd party developers to require special
build/link options. I have fought these kind of issues on OS X before,
a solution like I mentioned above will work everywhere at minimal cost.
Dan
On Jul 25, 2006, at 3:29 PM, Robert Osfield wrote:
Hi Daniel,
So good detective work.
Is it possible to get OSX to initialize like other OSs?
If not then we'll need to register all the buffers to be later
initialized to the correct size. Will need to think more about this.
Robert.
On 7/25/06, Daniel Larimer <[EMAIL PROTECTED]> wrote:
Robert,
That is effectively the 2nd line executed in main and I
set num ==
10 for my application so I know that I haven't hit 10.
Upon closer inspection of include/osg/buffered_value I
think I have
identified the REAL problem.
There is a difference between Linux and OS X when it comes to
allocating static variables. On OS X the static variables such as
s_extentions get allocated BEFORE main(), but Linux
doesn't allocate
them until their first reference.
Further testing reveals that Drawable::getExtensions(),
Shader::flushDeleted...(), and several other places are still
crashing even with
my patch.
The solution to this problem is non-trivial and would
require some
form of direct initialization of these values OR some way to set
DisplaySettings::instance()->getMaxNumberOfGraphicsContexts() before
main().
I put a print statement in the constructor of
buffered_value to see
when it is initialized and to what size. I then put a print
statement at the first line in main(), here is the out put.
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
buffered_value size: 1
[thread: (?)] [CoveAppInit.cpp:27 in CoveAppInit] Initializing static
Cove objects...
[thread: (?)] [AutoreleasePool.cpp:143 in init] Created static
AutoreleasePool stack.
[thread: (?)] [AutoreleasePool.cpp:29 in AutoreleasePool] Created new
AutoreleasePool at address 0xa422e30.
[thread: (?)] [CoveAppInit.cpp:34 in CoveAppInit] Finished
initializing static Cove objects.
[thread: (?)] [cove.cpp:15 in main] main
Ideas?
Dan
On Jul 25, 2006, at 2:36 PM, Robert Osfield wrote:
> On 7/25/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
>> I realise this is an unsual caveat of multi-threaded multi-context
>> work, but this its a small hurdle which gains you much better
>> performance - otherwise you have mutex commonly access methods
which
>> would kill performance.
>
> I forgot to mention the magic line is:
>
> osg::DisplaySettings::instance()->setMaxNumberOfGraphicsContexts
(num)
>
> osgProducer::OsgCameraGroup sets atomatically this for you in its
> constructor, so as long as you construct it before loading the
scene
> graph then everything is fine.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
