My wishes of the next release: just fixup, e. g. the OOM-killer situations

Just a bit time for a little rant. My actual experience is slowing down and OOM very often. The problems are adressed: the browser does have memory problems - as android. On my XA2 I have situations with very slow reactions of android apps (and I only use tt-rss and element). Cache cleaning did the job on former versions but now it does not help anymore. And the browser does what it wants. Opening up mastodon with it and all other apps are dead. Same with just reading a news page. More than two tabs: forget it!

It is no linux behaviour to reboot it twice a day!

And when you are just begin to fix it: Please fix the mozilla possioning MLP stuff too. It does not make sense to have a positioning just when arriving the destination (I do not mean 10km trips, more 150km!) :frowning:

9 Likes

Yes, @cy8aer , have a look at this thread to make it a little bit better:

[SFOS Browser] Solving the browser memory issue

2 Likes

Thank you for your advice. Just trying.

In the Browser settings (enter about:config into address line) I did this:
apz.content_response_timeout 200
apz.touch_start_tolerance 0.1 and remove the f - edit: 0.04
browser.cache.memory.capacity 2048
ui.click_hold_content_menus.delay 300
general.smooth.scroll off

edit:
apz.pinch_lock* (3 settings, all original 0.03125) edit: 0.05

This and to let Browser run alone (no other apps open at the same time) makes things remarkable better.

4 Likes

I’ll try that too though does increasing cache memory capacity makes sense for me?

I guess yes, the browser runs smoother with more cache. I guess it can fetch more data from cache (faster) and has less data to fetch over netwok (slower and delayed), that lets it less often crash.

Another thing is, if scrolling with finger (thicker), meanwhile it crashes very rare, but if scrolling with a stylus (thinner), it crashes more often. Also scrolling while images are still loading causes more crashes then scrolling while page is completely loaded yet.

Funny situations :-/ - but I now try your settings for the next days.

1 Like

Yes, situation is workable, but still dire.

See also Low memory, apps crashing - change zram settings or add swapfile? [4.x]

Rounding this variables from up to 6 decimales to 2 decimales apparently reduces CPU load (I guess…) and speeds up the Browser.

apz.axis_lock.breakout_angle 0.392699 → 0.4
apz.axis_lock.breakout_threshold 0.03125 → 0.03
apz.axis_lock.direct_pan_angle 1.0472 → 1.05
apz.axis_lock.lock_angle 0.523599 → 0.53

screen flickers one time after applying, but now works more faster.

edit:
general.smoothScroll.* partly on → all off

2 Likes

If those are proved to be effective should be enabled on future OS updates :slight_smile:

Yeah, keyword “if”. This all sounds a bit too much like voodoo.

1 Like

No no, this is no voodoo, @attah . I did it and it works. I was quite desperate about Browsers bad performance and therefore in my distress I just looked up what’s there and, according to intuition, turned off everything that could unnecessarily burden the processor.

With more luck than brains, I have succeeded. But I have to confess, I don’t really know why.

My ideas were:
browser.cache.memory.capacity 1024 2048
More cache is less data traffic over the network, that is slower.

general.smooth.scroll and general.smooth.scroll.* all off
Smooth scroll is CPU load, therefore off

apz.axis_lock.*
Seems to be relevant for screen and/or GUI. Calculations for angles in the UI with accuracy of 6 decimales I consider as imho senseless, so I rounded and reduced to 1-2 decimales. So calculation is faster.

apz.pinch_lock* (3 settings, all original 0.03125) → 0.05
made tapping easier, especially when using a stylus, but also with finger, and as above less decimales.

I made all tweaks on Volla. Next step is to repeat and hopefully confirm this on the X10, too. I will report as soon I’m ready.

And please, could someone who is more skilled than I check, test, add other relating settings I forgot, and explain what this tweaks really do and why it works?
I couldn’t find a complete and valid list of about:config settings in the net, searching with Startpage. Does somebody have one?

That’s basically the same thing unless you have experience in the area.

Last i checked floating-point multiplications did not vary how computationally expensive they are depending on the number of decimals. They have a fixed complexity.

3 Likes

It’s probably voodoo, but there’s too many sources of crashes to know for sure, maybe some are eliminated through some tweaks, sadly Visual Studio Code March 2023 still crashes reliably on XIII in mobile mode with all those tweaks, desktop mode works fine, also works completely fine on jolla C in both modes, crash is probably XIII specific to the media files on the site and broken media support (like originally all videos would cause a crash, hotfix was not thorough enough):

This is a non-oom crash as all background apps survive. There are oom crashes, there are device specific crashes, it’s a bloody mess

It may be that there is only one important tweak really necessary and the rest is more or less unnecessary. The main thing was removing the f from the apz.touch_start_tolerance value. This encouraged me to do further experiments. Now Browser works fast and fine, and now I’m going to give rest until the situation is cleared.

@throwaway69 My tweaks couldn’t completely solve the crash problem. There are still suddenly crashes happening from time to time. But the tweaks did speed up the browser is a way I never considered as possible. Therefore I’m now really very happy!

While I doubt the speedup floating points can cause all kinds of issues/crashes Floating Point in the Browser, Part 3: When x+y=x (y != 0) | Random ASCII – tech blog of Bruce Dawson

Now I applied my list of tweaks on the Xperia 10, with a remarkable gain in speed even when quick clicking in a list of Youtube videos.

This is the list:
Browser Tweaks Summary

Settings are in about:config, some of the apz settings look promising, like apz.touch_start_tolerance.

Please give these settings a try and report back what values you prefer.

apz.axis_lock.breakout_angle 0.392699 → 0.4
apz.axis_lock.breakout_threshold 0.03125 → 0.03
apz.axis_lock.direct_pan_angle 1.0472 → 1.05
apz.axis_lock.lock_angle 0.523599 → 0.53

apz.content_response_timeout 150

apz.pinch_lock* (3 settings, all original 0.03125) 0.05

apz.touch_start_tolerance 0.1 and remove the f - edit: 0.04

browser.cache.memory.capacity 2048

general.smoothScroll off
general.smoothScroll.* partly on → all off

ui.click_hold_context_menus off
ui.click_hold_context_menus.delay 300 or 200

Here 2 settings where I found a ‘f’ at the end:
Suspicious:
apz.fling_accel_base_mult 1.125f Has ‘f’ !!
apz.fling_stopped_threshold 0.13f

Next I’ll test what happens if I remove these two f’s, and will report.

edit: No noticeable difference to as it was before.

As said above, it speeds up the browser but unfortunately doesn’t prevent crashes. But I have the feeling they occur fewer now.

edit:
device.sensors.motion.enabled off
is another unnecessary thing to disable

edit:
And now, this is the last strange looking setting I found:
service.settings.last_etag “longNumber” (with quotation marks)
while all other variables there have no quotation marks. → removed them,
Browser runs like a charm now, user experience much smoother now, and I will report in a week if crashes still occur or not.

edit: Browser did crash again. (2023-05.02) edit: but only one time.

Testing now this (2023-05-06):
apz.drag.enabled on → off
apz.drag.initial.enabled on → off
apz.drag.touch.enabled on → off
apz.enlarge_displayport_when_clipped on → off

accessibility.accesskeycausesactivation on → off
accessibility.browsewithcaret on → off
accessibility.browsewithcaret_shortcut.enabled on → off

dom.vibrator.enabled on → off
dom.vr.oculus.enabled on → off (don’t have a oculus VR)
dom.vr.oculus.invisible.enabled on → off
dom.vr.poseprediction.enabled on → off
dom.vr.require-gesture on → off

edit 2023-05-13:

apz.autoscroll.enabled: off
apz.disable_for_scroll_linked_effects: on

edit: browser.cache.disk.max_entry_size: 4096 → 1024

I can’t imagine that a max. entry size of 4096 is good while the cache has only 1024 in size by default.

feedback is very welcome!

1 Like

Maybe this gives a bit of guidance regarding the settings:

https://kb.mozillazine.org/About:config_entries

Not all are documented, but a lot are. Hopefully now a bit less gessing :slight_smile:

Maybe some more tweaks to your liking can be found here:

https://wiki.archlinux.org/title/Firefox/Tweaks

1 Like

There is certainly no correlation between the lengh of a number in base 10 and the cost of calculations. But there might be a ton of reasons why small differences in numbers change computational cost. (e.g. Allows caching of processing steps, because obscure reasons… Aka voodoo :wink:

however the 0.4f, or whatever it was, might have been an invalid value and disabled the whole feature alltogether…

4 Likes

I just had a weird one. NOT having changed browser.cache.memory.capacity (so at default 1024) with 2 other apps running the browser shows ‘Memory allocation failed’! instead of the page (which is plain text html with no other content than text. That’s with the browser unmodified, no custom settings at all.

1 Like