Ticket #185 (new defect)

Opened 1 year ago

Last modified 1 year ago

ChangeList growing without bound

Reported by: dirk Assigned to: unassigned
Priority: major Milestone: 2.0 Beta
Component: System Version: 2.0
Keywords: Cc: vossg
Completion:

Description

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

07/21/07 05:36:46 changed by marcusl

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

07/29/07 22:09:12 changed by dirk

  • cc set to vossg.

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.

07/30/07 09:09:13 changed 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!)

07/30/07 14:01:46 changed by dirk

That was the idea, yes.