Memory leak in screencap.cpp

[Kenn]

There seems to be a memory leak when using the screencap.cpp on Mac
OSX 10.6.8. I suspect that this is coming from ScreenCapture since
when I toggle _sc->setCapture( !_sc->getCaptureEnabled() ); the memory
leak comes back or goes away, depending on whether I'm turning on the
screen cap or not.

The memory leak is large, on the order of 50-100MB/s, so this makes me
think that it is an image that is not being released. Can you if
confirm this behavior is seen on other systems?

I am using latest svn checkout.

[Paul Martz]

Hi Kenn -- For simple scenes that render at 60hz, the operation of writing to
disk is inherently slower than rendering. This is the entire purpose of the
osgwTools::ScreenCapture class: to perform the disk writes in a separate thread,
so that it doesn't block rendering.

In order to work properly, osgwTools::ScreenCapture keeps a queue of images that
have been captured and are waiting to be written. Because the disk writes are
slower than rendering, this queue typically grows over time, increasing the
memory footprint. Later, when you toggle capture off (or hit escape to halt
rendering), the write thread continues to process the queue, and the memory
footprint shrinks accordingly. For this reason, I believe there is no memory leak.

Hope that helps,
-Paul

[Kenn]

That certainly explains it. Judging by the file extensions, it looked
as if the program were simply dropping frames it couldn't write.

Do you happen to know how I could slow down the render process? I
don't need any more than 10-20 images per second. I realize I could
put a timer on the write thread, but naively it seems more natural to
slow down the render process, and thus save some processor cycles for
other tasks.

[Paul Martz]

Hm. Well, the whole point of osgwTools::ScreenCapture is to *not* slow down the
render thread. :-) So I think perhaps you are not using the right tool for the job.

if you don't mind blocking the render thread while you save the image, then you
don't need osgWorks. You should look at the osgscreencapture example that ships
with the OSG distribution. It blocks the render thread while it writes each
rendered image.

I don't know of a way to limit osgViewer::Viewer's framerate such that the CPU
is available for other tasks. Certainly you could call ::Sleep() between calls
to Viewer::frame(), but that would block the CPU. Perhaps someone on osg-users
would know more about this.
-Paul

[Doug McCorkle]

I believe that osgViewer has an on demand option that only renders images when things have changed or when the window is focused. I have not dug into this option but have only read about it on the list.

Doug

> --
> You received this message because you are subscribed to the Google Groups "osgworks-users" group.
> To post to this group, send email to osgwork...@googlegroups.com.
> To unsubscribe from this group, send email to osgworks-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/osgworks-users?hl=en.
>

[Kenn]

Thanks a million, that was exactly it:

viewer->setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND);
viewer->setRunFrameScheme(osgViewer::ViewerBase::CONTINUOUS);
viewer->setRunMaxFrameRate(double fps);

Are the three commands you can run for this. They work exactly as
advertised, and solve my pacing problem.

[Paul Martz]

Good to know, thanks.
-Paul