Page MenuHome

dope sheet zooming oddity regarding cpu usage
Closed, InvalidPublic

Description

System Information
xp 32bits

Blender Version
Broken: (example: 2.69.7 4b206af, see splash screen)
Worked: (optional)
not really applicable as it's not broken, but there's something is very strange see below

Short description of error
zooming in/out behaviour in dopesheet can increase CPU use a lot depending on how you zoom

Exact steps for others to reproduce the error

  • i change the 3D view to the dope sheet
  • i open whatever CPU usage monitoring program i have
  • i zoom in continuously with -mousewheel- (important) (i don't stop moving your mousewheel to zoom)
  • i observe the CPU usage increase progressively until +/- 54% during the mousewheel use

now other method :

  • i stop zooming in with your mousewheel
  • i hold CTRL , i hold your mousewheel button (or hold middle mouse button if you have one) and move the mouse to zoom that way, as before, i don't stop moving your mouse
  • first noticable difference is that the zooming that way is not only much faster, but it's very much smoother
  • 2nd noticable difference is that the CPU usage does not increase and stay very low actually.

After testing with past versions of Blender i noticed the last version in which the mousewheel zoom didn't had that odd CPU increase was 2.69, this apparently started with 2.70
(additionally i don't have a mouse manager program that could go crazy, it's all xp native mouse support)

As said it's not a bug to me as i usually use the hold CTRL hold MMB to zoom, just an oddity i observed and prefered to report in case it's not related to unsupported OS (as i'm on XP) but hide something else with windows.
I remember there was a CPU overuse problem on windows some time ago with OpenMP and the new mscv2013 compiller.

Details

Type
Bug

Event Timeline

Sanc Tuary (sanctuary) updated the task description. (Show Details)
Sanc Tuary (sanctuary) raised the priority of this task from to Needs Triage by Developer.
Sanc Tuary (sanctuary) set Type to Bug.

I tried this on OSX and could only get up to 15% both ways, and same with 3D view zooming as well. No anomalies here.

I can't see too much of a difference on linux either. Maybe a windows dev can check things here? @Thomas Dinges (dingto) or @Martijn Berger (juicyfruit)?

I managed to get a friend that had the same OS as me to try and he didn't observed much difference between the 2 zoom methods in term of CPU usage.
The bigger difference was that his system has 3 cores while i have 2 but unsure at that point if it's part of the problem.

The oddity to me is that this cpu noticable increase really only happen in the dopesheet with only the 1st zooming method, i have no such problem in the 3D view or when sculpting by example, i even tried the UV editor as it's 2D too and there again no problem, it seems to happen only in the dopesheet for me.

Julian Eisel (Severin) closed this task as Invalid.Nov 30 2014, 2:44 PM
Julian Eisel (Severin) claimed this task.

Hey @Sanc Tuary (sanctuary),
I had a look at this and can confirm CPU usage of > 50% with really fast zooming (using a mouse that can disengage the mousewheel, making really fast scrolling possible). However, this is sort of expected, as the CPU has to recalculate and redraw the entire region (I guess the most CPU power is needed to calculate the grid in the background). You can also recreate this in the Node Editor or the Timeline. I had a look at pre-2.7 versions, too, with the same result.

So thanks a lot for the report @Sanc Tuary (sanctuary), but luckily no bug here :)