Hi Robert, thanks for the quick answer. What I feel strange is the different behavior that the standard osgviewer class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms.
If I check the osgviewerGLUT example, the behavior looks almost identical in both osx and win32. Is there a way to disable the vsync check in a "plain" osgviewer application? I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG architecture yet... :) thanks again, Davide > > Date: Mon, 2 Feb 2009 14:47:28 +0000 > From: Robert Osfield <[email protected]> > Subject: Re: [osg-users] OSX issue with the osgviewer class > To: OpenSceneGraph Users <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > HI Davide, > > In what way is this a problem? It's quite normal for a viewer to wait > on barriers, as when you have vsync on the graphics thread will be > gated by the refresh of the monitor, with the OpenGL driver just > putting the calling thread to sleep while it waits for the next frame. > If you switch off vysnc you'll find much high CPU utilization as you > then see the frame loop throwing many for frames of data quickly at > the OpenGL fifo. > > Robert. > > On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet <[email protected]> > wrote: > > Hi to everybody, > > > > I'm having a problem under OSX with the osgviewer implementation. > > The application is using only 5 to 10% of the processor power, because > the > > most part of the time it is waiting on a mutex inside the > > osgViewer::ViewerBase::renderingTraversals() call. > > > > Exactly the same code (I'm creating a multi-platform application) under > > windows works like a charm; I can't try under linux. > > > > My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. > > Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and > > there is the same problem. > > > > Attached the call graph, with the number of milliseconds spent on each > > function call (out of a total time of 3 sec). > > As you can see, the renderingTraversal call performs 2 sub-calls: > > OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it > > waits for a huge amount of time (more than 95%). > > > > Call graph: > > 2091 Thread_2503 > > 2091 start > > 2091 main > > 2091 simpleGraphicsLoop() > > 2089 graphics::GraphicsManager::update() > > 2075 osgViewer::ViewerBase::renderingTraversals() > > 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) > > 2049 pthread_cond_wait > > 2049 _pthread_cond_wait > > 2041 semaphore_wait_signal_trap > > 2041 semaphore_wait_signal_trap > > 8 _pthread_cond_wait > > 24 osgViewer::Renderer::cull() > > 17 osgUtil::SceneView::cull() > > > > It's easy to reproduce the "problem" with the standard "osgviewer" > example > > distributed with the library. > > Does somebody encountered the same problem and, hopefully, solved it in > some > > way? or there is some workarounds? or maybe I'm making some stupid > > mistake... > > > > Thanks! > > Davide Bacchet > > > > __
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
