Hi there! I just started using Spine in my productive process and it really is an awesome tool.
But at the moment it's a massive performance hog too. I noticed it instantly as i tried debugging a game while Spine was running in the background. The game ran all stuttery and even using photoshop was all choppy too. That's when i noticed that Spine was the culprit, wasting 40% of the quad-core CPU and pretty much all of the GPU performance while sitting in the background completely idle and doing nothing. (On my more powerful gaming rig it's still wasting 20% CPU, but is less noticable.)
Wasting performance like this is a total no-go for a desktop application that will often times just sit idle in the background. That's why i consider this a bug, even though it doesn't break Spine's functionality.
Frist of all: I guess VSync isn't used at the moment? Because the amount of performance wasted seems very high for what Spine renders. Activating VSync by default could already lower the required processing power by a good amount.
Now for the actual fix: Spine seems to be rendering in a constant loop even when no animation is running and no input is made, wasting resources by redrawing the exact same screen over and over again. Drawing in a loop should only happen when an animation is actively running. Otherwise drawing should only occur when:
A) The window has focus and receives mouse or keybord interaction.
B) The window invalidates / receives a paint event.
This will reduce the required processing power to only a tiny fraction of what it is now while working with no animation actively running (because even mouse move events usually happen far less frequent than 60 times a second) and reduce it to pretty much nothing when it just sits idle in the background.
This is no pressing matter and i can avoid the issues caused by it by simply closing down Spine when i'm doing anything else. So no sweat while Nate enjoys his hopefully incredible honeymoon. I just hope it will be fixed at some point in the not too distant future so that the tool can be left open without wasting performance like crazy.
Страница 1 из 1
- Сообщения: 7
Odd. I put a passively cooled ATI card into my work machine that is just marginally more powerful than the previous NVidia card and WAY less powerful than the NVidia card in my gaming rig and CPU usage is down to 5%. I certainly wouldn't have complained about that. So it's an NVidia driver issue, i guess? Very odd.
- Сообщения: 7
Interesting, maybe some setting in the nvidia control panel is the culprit. I use an nvidia card myself and haven't had the problem. But thanks for reporting the issue, maybe someone else will run into it.
- Сообщения: 2382
Should use 15 fps when in the background and not playing an animation and 60 otherwise. This was done on OSX but not Windows, fixed now!
- Сообщения: 9288
Is the 15 fps at idle necessary? Most GUI programs I know of have some kind of event loop at their core that will simply sleep, waiting for events to arrive.Nate писал(а):Should use 15 fps when in the background and not playing an animation and 60 otherwise. This was done on OSX but not Windows, fixed now!
I hit this problem because on my lenovo x1 carbon laptop running Ubuntu 13.04, Spine takes ~30% CPU even when not running any animations. It affects other other rendering heavy programs running simultaneously as noted, but more importantly, it heats the laptop, spins up the fans and eats battery which is quite annoying.
Otherwise a great program, I purchased it almost immediately after stumpling upon it while researching 2d skeleton animation.
- Сообщения: 1
Spine is using OpenGL and is written like a game, so it renders many times per second. Non-continuous rendering could be done, but it is easy to miss triggering a redraw, especially when the UI framework it is built on is not designed for non-continuous rendering. The effort it would take hasn't been worth having it use less CPU. On my (admittedly beefy) laptop Spine uses 0-1% in the background and 0-3% in the foreground while playing animations.
- Сообщения: 9288
Mark topic unread • Страница 1 из 1
Вернуться в Bugs