Re: [Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?
On Mon, Mar 21, 2011 at 3:04 PM, Holger Wirtz dcored...@googlemail.com wrote: Hi all, sorry - a little bit off-topic (in fact not so much as you might think, it's for a third-party software for FG): Has anyone some hints/websites/programs for debugging C -based multi threaded programs (exactly: glib based C code)? Currently I am developing with vi and a little bit gdb (command line) and very much debug output. But this setup seems to be very frustrating while searching for dead-locks and race-conditions :-( On the other hand I won't invest too much time for studying rocket engeneering only to use framework XYZ. Has anyone some ideas how to debug with less effort? Just a couple of ideas to add to others' suggestions. First, if you are starting from scratch, do some reading on design of multi-threaded programs in order to reduce sharing -- and the potential for races -- right from the start. A good strategy is to set up queues of work for auxiliary threads and also have queues where those threads can place their results. The helgrind tool, which is part of valgrind, is very useful for rooting out race conditions at an API level. You might not be able to run FlightGear with it in a practical way, but you can certainly run graphical applications with it. In gdb there are several breakpoint and scheduling commands which give you the flexibility to only break in certain threads and to only let one thread continue. This can be useful when several threads have entered the same function (which might be perfectly reasonable) and gdb appears to be bouncing all around. Finally, command line gdb is intolerable; I haven't debugged that way for years. I run gdb inside of emacs, which gives you instant access to the source code. I won't push emacs on a vi user :), but there are many alternatives these days on Linux which will provide a friendlier debugging experience. Tim Thanks, Holger -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture cache
On 22.03.2011 23:54, Tim Moore wrote: 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. This should not be true in general; the images should be cached and the texture objects should be too, unless some parameter is animated so the texture can not be shared. Now, I notice that cacheing is turned off for a class of models that includes AI models and may include models created through Nasal (simgear/scene/model/SGPagedLOD.hxx, line 53); I don't know what the rationale is for that and that may be the cause of the current problems. The particular line disabling the OSG cache has been there from the very first commit (3 years ago to the day). So there is a chance, it was never really considered - or there was an issue with OSG library itself at the time. On my machine it seems ok to enable the cache - everything looks normal with FG. 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. Just make very sure to use a well controlled environment for any performance tests (especially no live weather...). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
I investigated further into the stuttering issue. I tried the UFO like ThorstenB suggested. Then I tried some other planes and found something interesting. There is regular stuttering with every plane I tested. But the interval between the stutters differs with every plane. See my results: C172p ~6.000 secjsbsim 747-400 ~5.100 secjsbsim 767-300 ~2.900 secyasim 777-200 ~4.000 secyasim Bravo ~1.300 secyasim ufo~41.000 sec All planes are from the git repositiry. What I can say is that yasim-planes seem to stutter more frequently than jsbsim-planes. With the ufo it's almost not noticeable unless you wait 41 seconds for the next stutter. @Csaba and others If you have time, could you please compare it with your numbers? I tested at LFML (Marseille) because I get good fps there. But any other place with good fps should be fine. The best thing to make the stutters more noticeable is to fly in the cockpit, fly a continuous steep turn in one direction (so you get a circle) and look to the ground. Use a stopwatch or use the clock on the panels of some planes. I wonder what may be the cause for these stutters. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture cache
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. I've just done a very quick test with a binary compiled with CACHE_ALL, and the result looks *very* promising. I've seen a 100x100 double-layer cloud config appear in the scenery less than 15 seconds - and that was while my second CPU was happily crunching some heavy numerics in the background, so there's some reason to expect it to be even better in reality. My previous binary with CACHE_NONE solved the same task under identical conditions in a bit more than 75 seconds. Quite possibly most of the time is now taken by setprop() statements writing into the /models/ section of the property tree (the time taken from the point where models start appearing in the scene is ~5 seconds) and by xml parsing. I'll investigate some more when I have more time and more free CPUs, but it seems that this is indeed what is needed. Cheers, * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mipmaps (was: Adventures in dds)
Shouting again from the back row, but I want to point out that pregenerated mipmaps is not something dds specific, it can be done with any texture format. It's just about storing them. Like in http://www.ogre3d.org/tikiwiki/img/wiki_up/MipMap_Example_STS101.jpg . Of course dds has the pro side that it is loaded directly into memory, no uncompressing is required. With e.g. png and the storing method above, the image needs to be decompressed properly to allow using the mipmaps. But it is possible. If we figured out a format to store mipmaps and how to use them in FG, it would allow using many more better filters for them, which might increase graphics quality a lot, just like was seen in the dds screenshots. And at the same time could allow for better compression (but slower loading times maybe) to save HD space if that is necessary. Also one thing point mentioning is that DDS format might not be supported on older hardware. And I think FG is supposed to support also older hardware. For reference, the dds loader source: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dds/ReaderWriterDDS.cpp?rev=3017 Zan -- Lauri Peltonen lauri.pelto...@gmail.com -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmaps (was: Adventures in dds)
On Wednesday 23 March 2011 13:32:25 Lauri Peltonen wrote: Also one thing point mentioning is that DDS format might not be supported on older hardware. And I think FG is supposed to support also older hardware. I think BC3/DXT5 is pretty well supported by older hardware. There would be issues with the BC5/ATI2 mode (used for normalmaps) which is a newer appearance (ATI-x800 timeframe and newer, nVidia too), but then again, I don't think the older hardware supports the shaders that would use these textures (bumpspec, reflectbumpspec.. etc). -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture cache
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 testing: It also works in practice. I have seen no averse side effects, and the performance drop from loading new clouds is now almost completely gone - the framerate drops I still see are mainly associated with terrain sampling. The actual rendering performance is, as far as I can see, not changed, i.e. once everything is there, it is there. But all in all this makes things way smoother. It should be most pronounced on single CPU machines. Many thanks for digging that up! * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Logitech Wingman Attack config file
Hi everybody, an old Logitech Wingman Attack happened to fall into my hands ... so I connected it to a Linux box (no way to make it work in Windows7!) and started playing with modprobe, fgjs and js_demo. Well, it works nicely with FGFS :-) It's an old simple gameport attached joystick but it works! Here's a link to a picture: http://www.vmart.pk/main/images/wingman%20attack.jpeg Now I'd like to share with you the .xml file I wrote down to make FGFS happy with it. Whom should I send the XML config file to? Cheers, Roberto -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
Hi,
I could reproduce the bug on my computer as well.
There seems to be some confusion about what the
SetLongitude()/SetLatitude()/SetAltitude()/etc. do in
src/FDM/JSBSim/JSBSim.cxx. On one hand, they are obviously intended to
update the initial conditions (IC) of JSBSim. And, when the IC are
updated, JSBSim assumes that a trim is needed. This is what happens when
the FDM is initialized or reset.
On the other hand, during a replay, these same functions are called but
with a somewhat different goal. Obviously the intent of 'replay' is not
to modify the IC of JSBSim but to fake the calculations of the FDM for
the purpose of displaying the aircraft at the right location and right
attitude. In this case there is indeed no need for a trim.
These two purposes are not really consistent hence the problem : JSBSim
gets lost about what the intent of FlightGear is.
Attached is a patch that fixes this bug (#294 in the bug tracker). As
far as I could test, it restores the functionality of the instant replay
while keeping the restart feature (CTRL+SHIFT+ESC) functional.
Furthermore I have implemented the 2 methods suspend() and resume() in
JSBSim.cxx so that the FDM is actually suspended during the replay.
However this bug fix is not really elegant because the original code is
not so elegant itself (see explanations above).
Bertrand.
Le lundi 21 mars 2011 à 20:06 +0100, ThorstenB a écrit :
Hi,
not sure if anyone else had a chance to test the instant replay with
JSBSim aircraft - but it indeed seems like a general issue to me. It's
triggered by JSBSim doing a trim operation once playback has
finished - which produces an output like this (with the F16 in this
case):
Trim Results:
Altitude AGL: 15 wdot: -1.83e+08 Tolerance: 1e-03 Failed
Pitch Angle:-19 qdot: 9.33e+07 Tolerance: 1e-04 Failed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 0 average: 0 successful: 0 stability: 3.5272
qdot: 0 average: 0 successful: 0 stability: 3
Run Count: 1201
Soon afterwards, the entire sim locks up since the FDM numerics go
wild. I can avoid this issue by suppressing the re-trim when replay
has finished (by forcing needTrim = false; in the code). All works
well for me then - but it completely kills the needTrim feature in
JSBSim, which was probably implemented for a reason...
The trim is triggered since the FDM still has its property listeners
connected during replay - so it thinks the aircraft position changes,
which sets the FDM's needTrim flag. Might be a good idea to
disconnect the FDM property ties during a replay - but JSBSim
currently doesn't allow to reconnect the ties (bind method is not
implemented). And the basic problem here probably is just that
something with re-trimming an aircraft doesn't work properly.
Any ideas on what could go wrong when the FDM tries to trim an already
trimmed aircraft?
cheers,
Thorsten
On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB bre...@gmail.com wrote:
I'm seeing an issue with the instant replay feature which seems to affect
JSBSim aircraft. The actual replay works, but once replay is finished, the
sim locks up or goes wild when trying to resume normal flight. Looks to me
as if the FDM was somehow messed up by the replay. The FDM's update is
suspended during replay - but I suspect there may be an issue with the tied
properties, which still allow the FDM to see the replayed movements. YASim
aircraft seem to be fine though.
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0eb2188..e2d98b6 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -570,6 +570,22 @@ void FGJSBsim::update( double dt )
/**/
+void FGJSBsim::suspend()
+{
+ fdmex-Hold();
+ SGSubsystem::suspend();
+}
+
+/**/
+
+void FGJSBsim::resume()
+{
+ fdmex-Resume();
+ SGSubsystem::resume();
+}
+
+/**/
+
// Convert from the FGInterface struct to the JSBsim generic_ struct
bool FGJSBsim::copy_to_JSBsim()
@@ -1011,7 +1027,9 @@ void FGJSBsim::set_Latitude(double lat)
_set_Sea_level_radius( sea_level_radius_meters * SG_METER_TO_FEET );
fgic-SetSeaLevelRadiusFtIC( sea_level_radius_meters * SG_METER_TO_FEET );
fgic-SetLatitudeRadIC( lat_geoc );
-needTrim=true;
+
+if
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Hi, I've pushed an update to sg/fg/fgdata which enables a (so far well hidden) feature of our subsystem manager to capture timing statistics. It''s now configurable at run-time. Use Debug - Toggle Subsystem Statistics to enable/disable. It prints min/max/average and std-deviation for each of FG's subsystems to the console. The statistics interval is configurable via /sim/timing-statistics/interval-s Since there are a lot of submodules in FG (most of them are very friendly and don't consume much time), you can restrict the output to modules exceeding a certain minimum execution time - or a certain jitter (hey!). Use /sim/timing-statistics/min-time-ms and /sim/timing-statistics/jitter-ms to configure the filters (in milliseconds, obviously). Should help finding performance and jitter issues if they were caused by one of our internal subsystems. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Wed, Mar 23, 2011 at 11:38 PM, ThorstenB bre...@gmail.com wrote: I've pushed an update to sg/fg/fgdata which enables a (so far well hidden) feature of our subsystem manager to capture timing statistics. I have found that feature earlier :) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. -- Csaba/Jester -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 23.03.2011 23:42, Csaba Halász wrote: I have found that feature earlier:) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. Yes, let's see what people come up with :). I actually see one submodule which produces some jitter. But I'm not a squealer. And my new machine is *very* fast... :) cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
On Thu, Sep 04, 2008 at 01:07:44PM -, I wrote: exactly the panel of the D-EEQA which I have been flying for some dozend hours already - some of you probably still remember this photo: http://foxtrot.mgras.net/bitmap/FGFS/DEEQA-LFLV02.jpg It looks like this bird is becoming the first FlightGear-specific real-life aircraft ! Sounds strange, but has a simple background: The price tag was low because it's currently not airworthy and requires some expensive parts to be replaced (prop immediately, gear in 136 hours). On the other hand the airframe or maybe even just the cockpit section makes a perfect eye-catcher for FlightGear presentations on public shows :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
On 23.03.2011 23:22, Bertrand Coconnier wrote: Attached is a patch that fixes this bug (#294 in the bug tracker). As far as I could test, it restores the functionality of the instant replay while keeping the restart feature (CTRL+SHIFT+ESC) functional. Furthermore I have implemented the 2 methods suspend() and resume() in JSBSim.cxx so that the FDM is actually suspended during the replay. However this bug fix is not really elegant because the original code is not so elegant itself (see explanations above). Thanks a lot Bertrand! Using the suspend/resume feature of the subsystem still is elegant, I think. During replay, we really don't want the FDM to do anything - preferably it shouldn't even notice that anything has changed at all. So, suspending the FDM and disabling its callbacks is a good idea. At least easier than disconnecting/reconnecting the property callbacks. It fixes all the issues I have seen and replay works fine now - so I pushed it to git. But are the JSBSim.* files officially maintained in the JSBSim repo (so the patch also needs to be proposed over there) - or are these files owned by FG now? cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
Martin Spott wrote: [...] On the other hand the airframe or maybe even just the cockpit section makes a perfect eye-catcher for FlightGear presentations on public shows :-) Note: This is a private adventure, no donated money will be used for this purchase, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
On Thu, 24 Mar 2011, Martin Spott wrote: On Thu, Sep 04, 2008 at 01:07:44PM -, I wrote: exactly the panel of the D-EEQA which I have been flying for some dozend hours already - some of you probably still remember this photo: http://foxtrot.mgras.net/bitmap/FGFS/DEEQA-LFLV02.jpg It looks like this bird is becoming the first FlightGear-specific real-life aircraft ! Sounds strange, but has a simple background: The price tag was low because it's currently not airworthy and requires some expensive parts to be replaced (prop immediately, gear in 136 hours). On the other hand the airframe or maybe even just the cockpit section makes a perfect eye-catcher for FlightGear presentations on public shows :-) Awesome find Martin! I bet you could part out the avionics to help pay for the conversion to a simulator. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Wed, 23 Mar 2011 05:56:49 +0100, robert...@web.de wrote in message AANLkTimUGMjCn2y=FWw4Avt6tx_5d3M=ywxsetz6w...@mail.gmail.com: ..maybe Robert can tell us the FG command line etc recipe he uses to provoke the 1Hz stuttering? My machine specs are: Athlon64 X2 5200+ Samsung HDD Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues) Debian unstable/experimental Kernels tested: 2.6.32 to 2.6.38 (no difference with stuttering issues) An old SoundBlaster 16 card ( i will try the --disable-sound parameter and report results later) I use GNOME as my desktop. (same here: will try to minimize autostart-programs in gnome-session-properties and report results later ) parameters I use: --enable-fullscreen --fov=60 ..I use --fov=90 and fullscreen routinely, usually 7 to 20fps, no stutter that I can see. --prop:/sim/rendering/multi-sample-buffers=true ..this segfaulted on my 3 day old git, will retest with todays. --prop:/sim/rendering/multi-samples=4 --enable-real-weather-fetch(will test without this one and report) --timeofday=noon --callsign=Robert --disable-ai-traffic ..no change on these. Hardware is ATI Mobility FireGL V5200 on x.org's radeon, display is 1920x1200x32bpp@60Hz, full list: https://github.com/gasguru/flightgearthings/blob/master/lshw @ThorstenB Thanks, I will try the UFO and maybe alter some XML files later. What system configuration do you use? @Csaba It seems it doesn't matter what CPU or GPU one uses. So it could be the OS or some i/o stuff inside flightgear or OSG. What OS do you use? ..Debian Sid + Experimental -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
