chrissimpkins / Crunch

Insane(ly slow but wicked good) PNG image optimization

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Max CPU on idle (Mojave, GUI)

adamtester opened this issue · comments

Describe the bug
Upon opening crunch GUI, CPU usage sits 94-98%, even when no image has been optimised.

To Reproduce
Steps to reproduce the behavior:

  1. Open 'application...'
  2. Open activity monitor

Expected behavior
No cpu usage while idle

Screenshots and/or Log Text
screenshot 2018-06-12 at 09 57 47

Adams-MBP:~ adamtester$ cat ~/.crunch/crunch.log
06-12-18 09:56:39	INFO	[ 42.47% ] /Users/adamtester/Downloads/menu-logo-crunch.png (1984 bytes)
06-12-18 09:56:39	INFO	Crunch execution ended.

Desktop (please complete the following information):

  • OS: macOs 10.14 Beta
  • Version: Crunch 3.0.0 GUI installed from prebuilt dmg

Additional context
Using beta macOS

Thanks for the report Adam. I just took a look at this on macOS Sierra and I can't reproduce the 90%+ range but it does sit at ~35% during the idle stage for me. This occurs both on fresh window open and when the idle view is displayed again following image processing. The only thing that the application is doing during the idle stage is render the animated gif (in HTML) in the view using WebKit. This seems to be an expensive task. I opened the same animation in Safari, Firefox, and Chrome and am seeing CPU usage of 20%, 15-20%, and 5-7% respectively. Mind opening the image on the path: /Applications/Crunch.app/Contents/Resources/02-Waiting@2x.gif in Safari and check your CPU usage as it renders the animation on Mohave? Perhaps something changed in WebKit animation renders in Mohave.

Irrespective of the findings that you see there, this is excessive even at 35%. We may need to consider reverting away from an animation during the idle phase. Will look into this in more detail.

Thanks again for reporting this issue.

cc: @garyjacobs (see note above about processor usage with display of the idle animation, thoughts?)

Yeah you are right, 22% if opened in safari, I ran it through a simple gif optimiser and didn't get much better.
It's odd as this is a fairly new mac, 16gb ram and i7, wouldn't have thought it would be a gif that makes it struggle!

Spongebob here: https://i.imgur.com/hsq78yr.gif
Gives around 3% usage when opened by itself in safari

Gif from the docs: https://raw.githubusercontent.com/chrissimpkins/Crunch/master/img/crunch-ss-2.gif
Gives 30% usage when opened by itself in safari

Thanks for looking at it. Still much higher in Crunch than in other applications. Let me look into it some more and see if I can find any improvements short of eliminating the idle time animation altogether. Will see if Gary weighs in. We may be able to improve the animation so that it is less taxing to render during idle.

I wonder though if the running animation while its compressing has a significant effect on the actual optimisation script?

For example on your machine would it run ~35% faster with no animation whatsoever?

You can verify by executing in the command line executable and comparing execution times.

As a GUI workaround for now, you can also use the right click menu service.

commented

That is really odd! It’s not even a large gif file.

Generally native apps (Mac) take advantage of GCD which improves threading performance but I’m not really sure why it would be chewing up that much cpu.

The only thing I can think is that because of the way the gifs are positioned in there (I think all three are vertically stacked) and they get moved on the Y axis depending on the state?. If that is accurate... then effectively that would be running all three gif (states) but hiding them out of the window view? Maybe 🤷‍♂️

Thanks Gary. I will have a look at and play with the HTML for those images. Even with draws of multiple small animated images we shouldn't be pinning the CPU on modern hardware. Strange.

I tested this on High Sierra and I am seeing CPU usage ~60% values there. This is a problem.

@garyjacobs are you willing to modify the idle/waiting image so that it executes the animation for, say, 2 - 3 secs and then animation ends? Or combine with the animated entry of the vice arms towards the central circle and end animation thereafter?

Alternatively if you do not have time for mods, would you be willing to share the masters and I can try to figure out how to do it myself?

they get moved on the Y axis depending on the state?. If that is accurate... then effectively that would be running all three gif (states) but hiding them out of the window view

And this is correct. I will see if I can change that behavior as part of the fix here.

commented

The idle gif only plays for 2 secs but just loops. Changing it should be a matter of dragging it into photoshop and re-saving it without the loop option checked. Not sure I can get to it today but if I can I will. Otherwise tomorrow👍

commented

Have you tried removing the gif and replacing it with something else to see if it is gifs in general or just the specific ones you use?

Have not attempted to replace them but can have a look at this over the weekend and will post here. 👍

Excellent, ty Gary! Will give them a try this weekend and let you know how it works out.

@garyjacobs that change seems to have done it! Thank you very much for modifying it. I really liked the continuous animations, but the system appears not to like it so much. I still find this bizarre... On my tests on Sierra 10.12.6, I am seeing idle state CPU usage of 0% both after initial application launch and after previous image optimization runs.

crunch-image

@adamtester Adam, do you mind giving the build in the link below a try? The tar.gz archive is packed with a build that is versioned 3.0.1-dev1 (version can be viewed in About menu) and can be installed with the installer included in the archive. If this fixes the problem for you, we will push this fix as v3.0.1.

Crunch-installer-3.0.1-dev1.tar.gz

@chrissimpkins yep just tried it and it works!

Excellent! Will push this today. Thanks for checking and thanks to Gary for the fix!

New release pushed as v3.0.1 with this fix. Homebrew cask update PR submitted (Homebrew/homebrew-cask#48667). Thanks again all!