[brightvalve]

Using the various tweaks the CMU is behaving much more to my liking, but one issue that remains (and isn't covered by any tweaks, AFAIK) is that it feels so slow. I'm running v56, EU (2016 Mazda 3).

Obviously, any hardware upgrades are out of the question (aside, perhaps, from overclocking the CPU, but I won't be doing that), but I'd like to know of anyone has tried any one of these things that I can think of that might speed things up a little:

• optimizing image files: some PNG files (not all) can be compressed (using something like OptiPNG) considerably, which would decrease loading time;
• removing CSS animations: the CMU's processor isn't very speedy, and I don't think it has a proper GPU that can hardware-render CSS animations;
• removing/shortening boot animations (/jci/resources/*.ivf)

If no one has tried these (or knows of other avenues to explore), I'll take a look at them myself (and share the results here, of course :laugh2 at some point.

Updates:

Boot Animations

Removing the boot animations is most likely a good way to bootloop your device, as some binary parts of the system (which aren't easy to patch) depend on them existing. However, shortening the animations works just fine, and especially shortening/replacing "TranLogo.ivf" seems to speed booting up a bit.

I initially replaced it by a 0.1 sec file, but this yielded some strange results. This animation is played between the "pulsating Mazda logo" animation (provided by "LoopLogo.ivf") and the home screen of the CMU (it's the one where the Mazda logo folds down and the home screen buttons appear).

If it's too short, for me, the view of the backup camera pops up (even when not in reverse and without a running engine) momentarily. I did make various longer-lasting animations, but in the end just replaced "TranLogo.ivf" with "LoopLogo.ivf" (which lasts 1 second).

If anyone's interested in playing with these files, this is what I used to shorten them (on macOS, using a Homebrew-installed ffmpeg):

ffmpeg -i TranLogo.ivf -t 0.3 -vcodec copy TranLogo.0.3.ivf

The CMU seems to play them without issue. VLC on the desktop can play them as well (IVF is a format that encapsulates VP8-encoded video frames with minimal metadata).

Reducing the length of CSS animations

I modified /jci/gui/common/controls/StatusBar/js/StatusBarCtrl.js, specifically the function transitionVisible, the limit the transition duration to at most 100ms. I have yet to test this properly, but at first glance it doesn't do a whole lot. Next thing to test is to set the duration to 0 to get instant transitions.

Also, I changed the various winkTimeout values from 3s to 1s (in /jci/gui/common/js/{Common.js,GuiConfig.js}). These are used for the "wink" control (which is a sort of dialog that pops up, for instance, when you mute/unmute) and set the duration between the control popping up and it fading away. The fade itself is a CSS transition that is set for 1s, which I left as-is.

 

[tarahumara]

Using the various tweaks the CMU is behaving much more to my liking, but one issue that remains (and isn't covered by any tweaks, AFAIK) is that it feels so slow. I'm running v56, EU (2016 Mazda 3).

Obviously, any hardware upgrades are out of the question (aside, perhaps, from overclocking the CPU, but I won't be doing that), but I'd like to know of anyone has tried any one of these things that I can think of that might speed things up a little:

• optimizing image files: some PNG files (not all) can be compressed (using something like OptiPNG) considerably, which would decrease loading time;
• removing CSS animations: the CMU's processor isn't very speedy, and I don't think it has a proper GPU that can hardware-render CSS animations;

If no one has tried these (or knows of other avenues to explore), I'll take a look at them myself (and share the results here, of course :laugh2 at some point.

Just remove navigation SD card when not in use if you have it to speed up. It nearly eats half of the cpu constantly.

 

[brightvalve]

Just remove navigation SD card when not in use if you have it to speed up. It nearly eats half of the cpu constantly.

Yeah you're right, that's one thing I also do. But I use the navigation regularly so would also like to apply some other speedups if possible.

 

[tarahumara]

Yeah you're right, that's one thing I also do. But I use the navigation regularly so would also like to apply some other speedups if possible.

Use a linux swap file. It helps a bit.

 

[yuikjh]

I thought perhaps I could disable some services in sm.conf that I didn't use (Pandora, DAB, etc), but I never got very far with it. It might be worth revisiting.

 

[tarahumara]

I thought perhaps I could disable some services in sm.conf that I didn't use (Pandora, DAB, etc), but I never got very far with it. It might be worth revisiting.

I don't think that will effect the performance much. Watch my video. It shows the cpu/memory load with and without sd nav card. Without sd card at idle it does not use much resource.

 

[brightvalve]

I don't think that will effect the performance much. Watch my video. It shows the cpu/memory load with and without sd nav card. Without sd card at idle it does not use much resource.

https://www.youtube.com/watch?v=gB_VwL6_vF0

My issue is mostly with the initial slowness when the CMU boots up and starts the interface (that just takes too much time IMO).

Once everything is loaded, speed is okay(-ish), but I'd like it to boot up to the main interface faster. That's why I focussing on limiting CPU usage (by getting rid of animations) and optimizing files (thus limiting the amount of data that needs to be read from slow flash).

 

[zephnath]

My issue is mostly with the initial slowness when the CMU boots up and starts the interface (that just takes too much time IMO).

Once everything is loaded, speed is okay(-ish), but I'd like it to boot up to the main interface faster. That's why I focussing on limiting CPU usage (by getting rid of animations) and optimizing files (thus limiting the amount of data that needs to be read from slow flash).

I compress the images in my themes. It really doesn't seem to make too much of a difference.

 

[brightvalve]

I compress the images in my themes. It really doesn't seem to make too much of a difference.

In terms of speed of loading, you mean? I was using a custom background (common/images/background.png) that was relatively large (about 200K).

I replaced it with a solid color PNG of about 2K, and it seems to pop up faster than before (but then again, I could contribute that to wishful thinking, I'm not timing it). But you know, shave a sec here, a sec there, and a 30 second boot may turn into a 20 second boot. Which for me would be a win :smile2: