Werner Modenbach writes:

> On Saturday 02 October 2010 11:52:08 Alberto Luaces wrote:
>> Changing the subject since this is a different topic.
>
> Sorry, was by accident.
>
>> 
>> Werner Modenbach writes:
>> > Can you please give a compareable short explanation on how frame() calls
>> > are generated and what happens inside then?
>> > The background of my question is the behaviour and the experience I got
>> > with Qt Adapterwidget. There we have a timer calling frame() every xx
>> > msec. On many systems this drives CPU activity to almost 100% - even if
>> > nothing happenes and nothing changed in the scene.
>> 
>> The best way of seeing it is in the source code. frame() is not a
>> complicated function at all, but launches the update, cull and render
>> traversals every time it is called. Obviously, if nothing in your scene
>> changes and you don't need to redraw, you could avoid calling it.
>> 
>> This is a snippet from frame (ViewerBase.cpp):
>> 
>>     eventTraversal();
>>     updateTraversal();
>>     renderingTraversals();
>
> Yes, I have seen this small sequence :-)
>
> But I have no idea which of the 3 calls takes so much CPU power, even if 
> nothing changed. Which method might cause my problems?
> What about the dirty flags? Can I use them in any reasonable kind to improve 
> the behaviour?
>

Even "nothing changed", OSG has to do the same work every time you call
frame() because it can't know -- almost nothing can be cached. Any node
of the graph could have been changed by the user since the last time, it
could exist update callbacks that behave differently according the time
or other events. The camera(s) position or configuration could have been
changed and now several new objects are visible or invisible while it
was the other way around the last time.

This is the common scenario for realtime applications. On the other side
for GUI applications, usually the scene is static until the user does
something. In that case, you only call frame() after keyboard, mouse,
redraw events... and you save all that redundant computations. This is
not specific to OSG or OpenGL, but it is a typical difference between
realtime and GUI applications.

In order to have a clearer lecture of what means every OSG traversal, I
recommend you to read the OSG's Quick Start Guide:

http://www.lulu.com/items/volume_51/767000/767629/3/print/OSGQSG.pdf

Regards,

-- 
Alberto

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

Reply via email to