Am 01.04.2012 18:25, schrieb Mathias Fröhlich:
> If you work with weak pointers/observer_ptr you need to use the lock method.
Ok, you're absolutely right. I wasn't aware of the "lock" method before,
indeed it has to be used here. I'll push a change. Thanks for reviewing
this!
cheers,
Thorsten
Hi,
I try to catch up on things past an other busy week.
On Thursday, March 29, 2012 00:22:46 ThorstenB wrote:
> Mathias, maybe you can have a look at the simgear changes. Maybe you see
> a way to improve this even further - i.e. do we still need all these
> cache maps? Or could we simply rely o
Hi,
I've pushed a fix for a larger memory issue, mainly affecting
effects/texture images, but also other objects. Once loaded, these stuck
in memory until shutting down flightgear - so memory consumption was
continually growing when flying larger distances.
Probably wasn't much of an issue ini
On Mon, Apr 18, 2011 at 9:55 AM, Tim Moore wrote:
> On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote:
>> There is
>> a global cache in simgear/makeEffect.cxx (effectMap), and it has no
>> condition to ever drop anything. So, created effects always stay in
>> memory until shutdown - hence also the
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote:
> On 16.04.2011 21:16, Anders Gidenstam wrote:
>> If I'm not mistaken the particles issue has been around since we got
>> particles, so it is apparently not that bad (leak and race
>> condition) in practice.
> Ok, thanks! I've create a bug issue as
On 17 Apr 2011, at 18:10, ThorstenB wrote:
> The effect/texture "mystery" is also solved - alas - explained. There is
> a global cache in simgear/makeEffect.cxx (effectMap), and it has no
> condition to ever drop anything. So, created effects always stay in
> memory until shutdown - hence also
On 16.04.2011 21:16, Anders Gidenstam wrote:
> If I'm not mistaken the particles issue has been around since we got
> particles, so it is apparently not that bad (leak and race
> condition) in practice.
Ok, thanks! I've create a bug issue as a reminder, in case someone else
noticed the issue some
On Sat, 16 Apr 2011, ThorstenB wrote:
> Ok, thanks a lot Anders for these hints! I'll open a tracker issue for
> the particle issue - so we won't forget these details. Can you estimate
> on how bad this issue could get? Does it only mean a minor memory leak -
> or could it get really bad over time
On 16.04.2011 16:24, Anders Gidenstam wrote:
> On Sat, 16 Apr 2011, Anders Gidenstam wrote:
>
> Hmm.. I should have added that I looked at this in early September last
> year so it is not fresh in my memory.
>
> IIRC the current code already does the fundamentaly unsafe operation of
> adding items
On Sat, 16 Apr 2011, Anders Gidenstam wrote:
> My failed attempt to unlink the particle systems might provide some insight
> into that issue. The attempt is broken because the
> methods calls
>if (!Particles::getCommonRoot()->removeChild(item)) {
> or
>if (!Particles::getC
On Sat, 16 Apr 2011, Anders Gidenstam wrote:
I think that is a different leak from the effects. IIRC each particle
system is attached to the scene graph in (at least) two places: at the
emitter's location in the graph and in a global vector of particle system
updaters. IIRC they are never remove
On Sat, 16 Apr 2011, ThorstenB wrote:
> Another observation: I started an MP session at KSFO (lots of MP
> aircraft), then warped to the middle of nowhere (no MP aircraft).
> After about 30min I dumped the scene graph. Surprisingly, loads of
> osg::particles were still *in* the scene graph, referr
Hi,
had another look at memory consumption. The FG multiplayer (=AI)
aircraft classes seem fine - they are created/removed as expected. But
there are problems with some of our OSG-based simgear classes: they
are never removed at run-time - hence memory is eaten up.
Problems start at simgear::Effe
On 13.04.2011 22:52, Csaba Halász wrote:
> On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB wrote:
>> I never ran FG for 6 hours with clouds& MP enabled though. But are we
>> sure that the OSG cache itself really made a major difference now?
>
> Yes, pretty sure. I fly FG during the monthly TGA events,
On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB wrote:
> * or it's all our fault, our leak alone - more or less unrelated to caching.
>
> I think the latter is (still) the case. I already posted some weeks ago
> that I was seeing loads of leaked objects. I managed to fix a few things
> at the time
>
>
On 13.04.2011 13:46, Frederic Bouvier wrote:
> To reduce memory footprint caused by model caching, I added this code to the
> begining of the main function of fgrun :
>
> osgDB::Registry* registry = osgDB::Registry::instance();
> registry->setExpiryDelay( 0. );
>
> I suspect we can control
> > You can say THAT again! I wonder if OSG people know that they should
> > also throw out stuff from cache, not just put things in!
> > I have been bold enough to use the CACHE_ALL for today's TGA
> > multiplayer event ... at the end of the 6th hour or so, FG's memory
> > usage reached 7.5GB, wit
On Wed, Apr 13, 2011 at 1:29 PM, wrote:
>
> I've got a stupid question - maybe someone who knows these things can
> educate me.
>
> If I do not use texture caching, textures are loaded from harddisk every
> time I need them, for each and every model.
>
> If I do use texture caching but my memory
> You can say THAT again! I wonder if OSG people know that they should
> also throw out stuff from cache, not just put things in!
> I have been bold enough to use the CACHE_ALL for today's TGA
> multiplayer event ... at the end of the 6th hour or so, FG's memory
> usage reached 7.5GB, with the exte
On Sun, Apr 3, 2011 at 11:39 PM, Tim Moore wrote:
> On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB wrote:
>> I've also been using CACHE_ALL since then - not seeing any problems. But
>> I haven't checked memory consumption. So, what's the status about the
>> OSG caching options, should we enable these?
On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB wrote:
Maybe someone could do some tests when changing the setting
>> (SGPagedLOD.hxx:56) from "CACHE_NONE" to "CACHE_IMAGES" or even to
>> "CACHE_ALL" (then recompile/install sg+fg). Would be interesting to
>> know
>> how this
On 03.04.2011 16:18, Torsten Dreyer wrote:
> Me, too. I had a few coredumps with the 4-nvidia-cards, 8 monitors
> (multithreading=automatic) setup since I had that enabled. I was not able to
> backtrace and blame it to the CACHING-Option, however. So this might just be a
> random correlation.
In fa
> I've also been using CACHE_ALL since then - not seeing any problems. But
> I haven't checked memory consumption. So, what's the status about the
> OSG caching options, should we enable these? Tim?
Me, too. I had a few coredumps with the 4-nvidia-cards, 8 monitors
(multithreading=automatic) setup
>>> Maybe someone could do some tests when changing the setting
>>> >> (SGPagedLOD.hxx:56) from "CACHE_NONE" to "CACHE_IMAGES" or even to
>>> >> "CACHE_ALL" (then recompile/install sg+fg). Would be interesting to know
>>> >> how this changed loading times, run-time fps and memory consumption.
>
24 matches
Mail list logo
