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 on
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'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
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB bre...@gmail.com 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
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 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
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
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, referring
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
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
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 to a
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
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
On Wed, Apr 13, 2011 at 1:29 PM, thorsten.i.r...@jyu.fi 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
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
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 the
On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB bre...@gmail.com 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
On Sun, Apr 3, 2011 at 11:39 PM, Tim Moore timoor...@gmail.com wrote:
On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB bre...@gmail.com 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
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.
After 30 minutes more of
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
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 fact
On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB bre...@gmail.com 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 changed loading
22 matches
Mail list logo
