Opened 10 years ago

Last modified 8 years ago

#185 assigned task

ChangeList growing without bound

Reported by: dirk Owned by: vossg
Priority: observe Milestone: 2.0 Beta
Component: System Version: 2.0
Keywords: Cc: vossg

Description (last modified by vossg)

Allen wrote:

I have been trying to track down some memory leaks in my application

today and I noticed that the _changedStore and _createdStore vectors in

OSG::ChangeList? seem to grow without bound in all the current sample

applications and tutorials. It looks like there is no where in the

system that ever calls clear (or commitChangesAndClear or ...) to

actually apply and clear the change lists.

I know I don't understand the change list code very well, but this seems

like a "bad thing".

Is this something that the user just needs to remember to do once per frame?

Andreas wrote:

adding a Thread::getCurrentChangeList()->clear() in the glut display

callback should fix this but that's not very nice. Perhaps we should add

this to the SimpleSceneManager? redraw method?

Change History (5)

comment:1 Changed 10 years ago by marcusl

Aren't changelists read-only by default in the samples/tutorials? As they are in 1.8?

comment:2 Changed 10 years ago by dirk

  • Cc vossg added

No, 2.0 needs the CLs, as it doesn't have the luxury of a user calling endEdit. ;)

We could add some commitAndClears to strategic places (e.g. Window::redraw), but I think it would be cleaner to add a check there and warn the user about uncommitted changes so that they can do the right thing, whatever that is for the app.

comment:3 Changed 10 years ago by marcusl

Why not add a check in window::redraw that prints: 'warning: rendering with non commited changes! Call CommitAndClear?!'

OTOH, if the overhead is small compared to rendering the frame, it might be worth it to do it, to help users handle this, at least for rendering? (For other things, it's similar to 1.x, i.e. to get side-effects of updates, use endEdit or commitandclear!)

comment:4 Changed 10 years ago by dirk

That was the idea, yes.

comment:5 Changed 8 years ago by vossg

  • Description modified (diff)
  • Owner changed from unassigned to vossg
  • Priority changed from major to observe
  • Status changed from new to assigned
  • Type changed from defect to task

I readded the read only feature. So the changelist should have a bound size, e.g. roughly by the number of active containers. Currently it's not enable by default (OSG_ENABLE_DEFAULT_READONLY_CHANGELIST). Changed priority to observed. I also added a general commitChanges before the windows render the viewports so that dependent elements (e.g. states) are up-to-date.

Note: See TracTickets for help on using tickets.