In the meanwhile I found a way to get the screen refresh rate to use as default
in the timer. I don't know if there is something helpful in the OSG libs but
since nobody answers ... here is the code:
DEVMODE lpDevMode;
memset(&lpDevMode, 0, sizeof(DEVMODE));
lpDevMode.dmSize = sizeof(DEVMODE);
l
hybr wrote:
> Hi, Gianni Ambrosio
> It can be the case that in old drivers vsync were disabled, and in new ones
> its enabled by default.
>
OK, it seems I got the point but I have some questions.
Basically the monitor refresh rate is 60Hz but the timer to update the widget
was 10 milliseconds
Looking at the posts It seems somebody uses OSG viewers embedded in Qt widgets.
Could you please give me a feedback regarding my problem?
Thanks
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39419#39419
___
Well, updating the driver works fine. But I have a couple of questions.
On my PC (WinXP) at the end of the day I experience the same bad behaviour
while if I restart windows the CPU usage is very low. Any explanation for that?
Moreover, which is the core problem in OSG related to that?
Regards
Hi Glenn
I tried the changes and it works good with many of the ..\test\.earth files.
That is a great change.
Thanks
Neil
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36987#36987
___
osg-users m
FYI, I just pushed a fix to make osgEarth work correctly with
--run-on-demand.
Glenn Waldron : Pelican Mapping
On Sun, Feb 20, 2011 at 11:34 AM, Neil Neilson wrote:
> Hi Jean
>
> I tried the --run-on-demand in a .bat file
> osgviewer --run-on-demand C:\OpenSceneGraph-2.9.9\data\cessna.osg
> Th
Hi, Gianni Ambrosio
It can be the case that in old drivers vsync were disabled, and in new ones its
enabled by default.
Cheers, Sergey.
22.02.2011, 18:01, "Gianni Ambrosio" :
> Hi All,
> I found a strange behaviour in a QT application using OSG. On a PC with a
> NVIDIA Quadro FX 550 gfx card t
Hi All,
I found a strange behaviour in a QT application using OSG. On a PC with a
NVIDIA Quadro FX 550 gfx card the CPU usage was 50% just running my qt app with
an osg Viewer.
After several investigation we updated the gfx card drivers to 6.14.12.6705 and
the cpu usage magically fell down.
Do
Hi hybr,
Thanks for the info, I have had problems with the Intel 945G
Intel was just getting into the video card/drivers
6.14.10.4436 2006 is Toshiba's version of the latest driver
Previously I had to get an older driver for Java's jogl (JNI of OpenGL)
I just tried
winxp_14324.exe 6.14.10.4
Hi, Neil.
iglicd32.dll is intel opengl driver dll, and apparently they are not so good at
writing opengl drivers atm, i've had some problems with intel cards and it's
ends up being driver bugs from time to time. If ossimplanet use compressed
textures try to enable them in graphics options in dri
Hi Norman
That code looks interesting. I would need to step through that and use
some std::cout to understand it.
I tried a half dozen times to install with ossimplanet 1.8.4. It shows the
globe and
terrain but MS ends it with iglicd32.dll. It said the log would be in ..\TEMP
or sometimes
On Feb 21, 2011, at 12:38 AM, Neil Neilson wrote:
> Hi Jean
>
> My third notebook has a Mobile Intel(R) 945GM Express Chipset
> That is the one I use most for development.
> The refresh rate is set at 60 Hertz
> I don't know if that is the vsync you are referring to.
> If it is then osgEarth mus
Hi Jean
My third notebook has a Mobile Intel(R) 945GM Express Chipset
That is the one I use most for development.
The refresh rate is set at 60 Hertz
I don't know if that is the vsync you are referring to.
If it is then osgEarth must be changing it because when zoomed way out
pressing the S key sh
Hi Neil,
I have 2 Notebooks with ATI and a Desktop NVIDIA cards. Changing something
there
would not help if an app is run on someone else's computer but that is good to
know.
My comment about the differences between ATI's drivers and Nvidia's only
concerned *default* settings. You can make
Hi Jean
I tried the --run-on-demand in a .bat file
osgviewer --run-on-demand C:\OpenSceneGraph-2.9.9\data\cessna.osg
That worked very well, the CPU was nearly 0 when the image was not being
changed.
I have 2 Notebooks with ATI and a Desktop NVIDIA cards. Changing something
there
would not hel
Hi Neil,
After trying the examples using a pre-built 2.9.9 and the latest from the SVN
built with VS10 the CPU usage is high.
On a dual core one is nearly max and the other core is minimal.
Apart from the run on demand functionality that others suggested, you
should make sure vsync is enable
Hi Ralf and Glen,
It's good to know something has been done on this.
Maybe osgearth_viewer will have the same capability before long.
Usually when an app does not have scope the CPU drops.
Even when an example is minimized to the task bar the
CPU is the same but switches which core uses the mo
Neil,
osgviewer --run-on-demand
(probably doesn't work with osgEarth at the moment though.)
Glenn
On Sat, Feb 19, 2011 at 1:15 PM, Neil Neilson wrote:
> Hi,
>
> What can be done to reduce CPU usage when the image is not being
> changed/updated?
>
> After trying the examples using a pre-built
Hi Niel
I have not tried this myself, but I remember that support was added for
manually handling the render loop.
OSG will default to a render loop that follows your screen refresh, and if
this is forced off it will redraw as fast as possible. But i think there is
support for handling when to in
Hi,
What can be done to reduce CPU usage when the image is not being
changed/updated?
After trying the examples using a pre-built 2.9.9 and the latest from the SVN
built with VS10 the CPU usage is high.
On a dual core one is nearly max and the other core is minimal.
With an app that much of
Try Windows Performance Analysis Tools
They use the kernel already in place hooks to collect statistics.
http://msdn.microsoft.com/en-us/performance/cc825801.aspx
http://blogs.msdn.com/pigscanfly/archive/2008/03/02/using-the-windows-sample-profiler-with-xperf.aspx
http://msdn.microsoft.com/en-us/li
Hi Cory,
In general I'd recommend doing all benchmarking with a system as near
to final delivery as possible, so no external tools, definitely no
debug build, run with vsync on etc. The OSG itself has some
performance stats that you can use, for instance osgviewer has the
StatsHandler added to th
On Mon, Jun 8, 2009 at 3:59 PM, Cory Riddell wrote:
> Hi Robert,
>
> On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddell wrote:
>
>
> Does anybody see less than 100% CPU utilization when running osgviewer
> cow.osg on an ATI card? I had just been accepting that as normal.
>
>
> 100% CPU is not normal at a
I had my cpu monitor open while running osgviewer. I just noticed that
after closing the cpu monitor, my vsync'd framerate immediately jumped
to 60 (the monitor native rate).
So, it seems that Heisenberg has struck again. I can't measure the
thing with out radically changing it. Or perhaps I'm
Hi Robert,
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddell wrote:
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
100% CPU is not normal at all.
Yikes! I think there must be somet
Hi,
Jean-Sébastien Guay wrote:
> Hi all,
>
>> I doubt that's the case if he's just running cow.osg. More likely,
>> VSync is not being properly detected on the ATI system, so the viewer
>> is just running free and not waiting for the frame to be drawn on the
>> screen.
>
> I think Jason's guess i
Hi all,
I doubt that's the case if he's just running cow.osg. More likely,
VSync is not being properly detected on the ATI system, so the viewer is
just running free and not waiting for the frame to be drawn on the screen.
I think Jason's guess is right on the money. Check your frame rates,
Hi Cory,
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddell wrote:
> Does anybody see less than 100% CPU utilization when running osgviewer
> cow.osg on an ATI card? I had just been accepting that as normal.
100% CPU is not normal at all.
Running osgviewer cow.osg on my Intel Core i7 + Radeon 4670 + K
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
Cory
Jason Daly wrote:
> Cory Riddell wrote:
>> I had asked about this one time and in the end I decided that it was
>> using 100% of one core intentionally. Th
Cory Riddell wrote:
I had asked about this one time and in the end I decided that it was
using 100% of one core intentionally. The run loop is not throttled in
any way, and so I think it will use as much cpu as it can.
Perhaps the nVidia system is better at offloading working or blocks the
CPU d
Out of curiosity, do you get similar frame rates on the two systems? Are
the other stats similar?
I had asked about this one time and in the end I decided that it was
using 100% of one core intentionally. The run loop is not throttled in
any way, and so I think it will use as much cpu as it can.
Hi,
Sorry for reusing this old thread. It seems that nobody has found a
solution for the problem yet that also works for me.
When running "osgviewer cow.osg" on a dual-core PC, I get a CPU usage of
50%, which indicates that one core is used at 100%.
System:
ATI Mobility Radeon HD 2400
Windows XP
I'm running locally now and am seeing the same behavior. Running with
--SingleThreaded makes no difference.
Cory
On Mon, Feb 2, 2009 at 9:53 AM, Adrian Egli OpenSceneGraph (3D) <
3dh...@gmail.com> wrote:
> Hi J-S
>
> i am working with NVidia GPU, and i have same behaviour. So there should be
> a
Hi J-S
i am working with NVidia GPU, and i have same behaviour. So there should be
another problem than the busy wait. Of course can VSync give some problem in
performance or at least we get a smaller FPS displayed. But here we have
some strang behavior of our osgViewer (renderer). My there is a b
Hi Cory,
I'll have to defer to others on the situation under Windows when doing
remote desktop. My guess is that it's likely to be a driver issue.
Well, using Remote Desktop adds a variable into the mix for sure, so
eliminating this and running the app locally would eliminate one
possible t
Hi Adrian,
Even with --SingleThreaded option one core is used at 100%.
Tell me if I should do other tests.
On Mon, Feb 2, 2009 at 9:25 AM, Adrian Egli OpenSceneGraph (3D) <
3dh...@gmail.com> wrote:
> Greate news (or bad news) that means we have not a windows issue. what
> happens when you switch
Hi guys,
Just one more data point: a colleague of mine tested our OSG app in
linux last week and also found one of the cores (on his 8 core
machine) utilising 100% cpu. After some investigation, this turned
out to a call to schedyield on the thread in the gl driver. Posibly
you are seeing someth
Greate news (or bad news) that means we have not a windows issue. what
happens when you switch to singelthreaded ?
/adrian
2009/2/1 Simon Loic
> Hi,
> in my case when I am runing osgviewer on a ubuntu distribution with 4 cores
> I get 25% of cpu, which means that one of my cores is over used. O
Hi,
in my case when I am runing osgviewer on a ubuntu distribution with 4 cores
I get 25% of cpu, which means that one of my cores is over used. One of my
colleagues have exactly the same behavior. Thus I don't think this is
windows related only.
On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron wrot
Adrian,
I have observed an intermittent problem on Windows in which osgviewer
starts up using a high CPU %, but then cycling through the threading
modes with 'm' makes the problem go away - even when you return to the
mode in which you started. I never did figure out why.
Just a data point...
G
Hi Adrian,
This sounds like it could be a barrier that Windows is implementing
inefficiently, and locking up a core whilest sitting on a barrier.
This could possibly be a issue with OpenThreads implementation under
Windows, or even just the OpenGL driver issue.
Are you running the app when Areo
Hi Cory,
I am working with Windows Vista dual core system. I get 50% CPU usage when i
am running osgviewer cow.osg if i start
osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i
have about 0.5-3% CPU usage !
i am very busy at the moment, but may tomorrow i will debug the
Hi Cory,
I'll have to defer to others on the situation under Windows when doing
remote desktop. My guess is that it's likely to be a driver issue.
Robert.
On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell wrote:
> I'm not sure about vysync. I'll look that up and check it.
>
> I thought about the p
I'm not sure about vysync. I'll look that up and check it.
I thought about the possibility of it being a debug build and I don't think
that's it. In my bin directory I have osgviewer.exe at 25,600 bytes and
osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU
pegging behavior (as
Hi Cory,
It's not normal to have this high level of CPU usage for this model,
the expceptions to this would be:
You have vysync switched off, so the app is racing as fast it can
to dispatch frames
You've compiled the OSG with debug build.
Robert.
On Fri, Jan 30, 2009 at 8:36 PM, Cory Ri
When I run the osg viewer app and load just about any osg file (like
cesna.osg), my CPU usage is a constant 23% - 30%. This is with no
interaction, it is basically using an entire CPU core. Fortunatelly I have a
4 core machine, so it hasn't been a problem so far, but I'm wondering what
this means f
46 matches
Mail list logo
