Let's see, there's a really weird problem on rendering, I've found that having opened Adobe Dreamweaver CS5 and running any application using Irrlicht screw up the app rendering doing it rendering when the window lost the focus (background) and eating more than 50% of cpu, until I move the (irrlicht based project) window, then everything starts to work well and the CPU consumption is reduced to 25%..
This is happening to me on Macbook Pro i5, Lion 10.7.3 and Intel HD Graphics 3000 512Mb and Irrlicht rev. 4136 /trunk, what worries me is this could happen in other platforms or even with other applications running..
- Only happens on windowed mode
- Steps to Reproduce:
1. Open Adobe Dreamweaver CS5
2. Open any demo binary
I've tried to check the app using profiling to verify where the CPU time is eaten but couldn't find it..
Cheers,
App start bug on OSX
Re: The latest SVN bugs thread
Ok, first of all this has nothing to do with this thread I guess - unless this is some problem you didn't have with non-svn versions.
Then games and 3d applications usually eat up more processing power - the reason is that games have to refresh the whole window each frame. But most Irrlicht examples have a sleep call somewhere to avoid taking the whole processing power. So would be interesting which binary you run exactly.
And also testing with Dreamwaver... uhm... doesn't mac have something like a Process Manager to see how much calculation time is used up?
Then games and 3d applications usually eat up more processing power - the reason is that games have to refresh the whole window each frame. But most Irrlicht examples have a sleep call somewhere to avoid taking the whole processing power. So would be interesting which binary you run exactly.
And also testing with Dreamwaver... uhm... doesn't mac have something like a Process Manager to see how much calculation time is used up?
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: The latest SVN bugs thread
I'm sorry for the wrong thread, by the way, guess I didn't myself clear. I'm not worried about the CPU use, what I'm trying to say is, that while the abnormal behavior is happening (when the irrlicht window is focused but any of the rendering is done, this is the main problem) the CPU is high and seems that any of the "drawAll" functions are being called, after I move the window or I quit Dreamweaver, the render starts to render correctly and the CPU is reduced to a 23% (which for me is pretty good), this is a really weird case, but the bug I guess is somewhere on the render process, because inside the game loop I'm updating window title with FPS info and it reach 3500 fps easily, so the window is being updated but none of the draw/update functions seems to work in that moment.CuteAlien wrote:Ok, first of all this has nothing to do with this thread I guess - unless this is some problem you didn't have with non-svn versions.
Then games and 3d applications usually eat up more processing power - the reason is that games have to refresh the whole window each frame. But most Irrlicht examples have a sleep call somewhere to avoid taking the whole processing power. So would be interesting which binary you run exactly.
And also testing with Dreamwaver... uhm... doesn't mac have something like a Process Manager to see how much calculation time is used up?
About the CPU time, what I was trying to do is run any of the demos with the Automation Profiler to reach the function that is not working well (since I don't know very well the irrlicht engine code), that's all.
Sorry for my english!
Cheers,
Re: The latest SVN bugs thread
when window is not focused you should sleep (by calling "yield"). Even if you are not doing drawing also a small loop can eat up whole cpu power (assuming you have a multicore probably you have a fully used a single CPU). When window stop rendering you should also sleep that window else there is no gain in stopping rendering for CPU usage. (yes because your window has no focus, but your executable is still running!)
It's probable that stopping rendering increase CPU usage. That's not a bug of irrlicht and not a bug of drivers of your video card's manufacturer.
When you are calling "Swapbufers" (should be "beginScene" or "endScene") video drivers tells to your machine to wait a moment so that while swapping Operative system can do other tasks. If you are not swapping buffers there is no longer any wait. ( in reality there are other "wait". Certain rendering calls will freeze your rendering loop but also makes able your PC to do other things in the meanwhile). So the expected behaviour is to use the whole available CPU power (and that's what you think is a bug). If that don't happens when rendering is thanks to advanced video drivers from video cards' vendors.
scheduler don't know if your loop is just a waiting loop unless you put a Sleep(1) somewhere. There are other ways like changing process priority but it's better don't play with priority unless you know what are you doing.
It's probable that stopping rendering increase CPU usage. That's not a bug of irrlicht and not a bug of drivers of your video card's manufacturer.
When you are calling "Swapbufers" (should be "beginScene" or "endScene") video drivers tells to your machine to wait a moment so that while swapping Operative system can do other tasks. If you are not swapping buffers there is no longer any wait. ( in reality there are other "wait". Certain rendering calls will freeze your rendering loop but also makes able your PC to do other things in the meanwhile). So the expected behaviour is to use the whole available CPU power (and that's what you think is a bug). If that don't happens when rendering is thanks to advanced video drivers from video cards' vendors.
scheduler don't know if your loop is just a waiting loop unless you put a Sleep(1) somewhere. There are other ways like changing process priority but it's better don't play with priority unless you know what are you doing.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Re: The latest SVN bugs thread
The window IS focused and it's not rendering at all until I move the window on the screen or close dreamweaver (which is running in background). That couldn't be a normal behavior.. Maybe I should make a video to show the behavior..REDDemon wrote:when window is not focused you should sleep (by calling "yield"). Even if you are not doing drawing also a small loop can eat up whole cpu power (assuming you have a multicore probably you have a fully used a single CPU). When window stop rendering you should also sleep that window else there is no gain in stopping rendering for CPU usage. (yes because your window has no focus, but your executable is still running!)
It's probable that stopping rendering increase CPU usage. That's not a bug of irrlicht and not a bug of drivers of your video card's manufacturer.
When you are calling "Swapbufers" (should be "beginScene" or "endScene") video drivers tells to your machine to wait a moment so that while swapping Operative system can do other tasks. If you are not swapping buffers there is no longer any wait. ( in reality there are other "wait". Certain rendering calls will freeze your rendering loop but also makes able your PC to do other things in the meanwhile). So the expected behaviour is to use the whole available CPU power (and that's what you think is a bug). If that don't happens when rendering is thanks to advanced video drivers from video cards' vendors.
scheduler don't know if your loop is just a waiting loop unless you put a Sleep(1) somewhere. There are other ways like changing process priority but it's better don't play with priority unless you know what are you doing.
Thanks!
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: App start bug on OSX
Ok, I've split this topic away from the SVN bugs thread.
Video might be a good idea, though I think I already understand. But this sounds more like a problem with the context creation or so. I also support the suggestion that in case of a failing render process the app might run wild and take more CPU time than necessary. Usually the render calls will block the app for a moment. In case these calls return immediately, all the remaining work is done by the CPU, which will always use up all the CPU time of the processor it runs on. Unless you call yield or sleep somewhere. Why this all happens, though, is so far not clear to me. Maybe Nadro has an idea. And btw, are you sure you use OpenGL and not the SW renderer? Because the latter did not work under OSX so far. Was only fixed lately.
Video might be a good idea, though I think I already understand. But this sounds more like a problem with the context creation or so. I also support the suggestion that in case of a failing render process the app might run wild and take more CPU time than necessary. Usually the render calls will block the app for a moment. In case these calls return immediately, all the remaining work is done by the CPU, which will always use up all the CPU time of the processor it runs on. Unless you call yield or sleep somewhere. Why this all happens, though, is so far not clear to me. Maybe Nadro has an idea. And btw, are you sure you use OpenGL and not the SW renderer? Because the latter did not work under OSX so far. Was only fixed lately.
Re: App start bug on OSX
so your bug was that rendering stops even with focused window not that cpu usage increase .you mentioned cpu usage increase (wich is normal behaviour if no rendering is done) so i thought your only problem was that..
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me