Bug 263558

Summary: Okular performance options: re-adjust outdated memory performance profiles
Product: [Applications] okular Reporter: TR <tobias.rudert>
Component: generalAssignee: Okular developers <okular-devel>
Status: RESOLVED FIXED    
Severity: wishlist CC: richard.llom
Priority: NOR    
Version First Reported In: 0.11.2   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description TR 2011-01-18 16:58:59 UTC 
Version:           0.11.2 (using KDE 4.5.5) 
OS:                Linux

In okulars performance options exist 3 performance profiles: low, normal and aggressive. These profiles point to less than 256 MB, 256 MB and 512 or more MB memory.

This classification is obviously outdated, since 95% of all sold machines have 1 GB of RAM or more and propably a lot of systems running KDE have 2 gigabyte or more.

So the current profiles...
-seem to be dusty and outdated for a user, since they represent the state of 2003 hardware
-dont help users to choose a profile that suites their hardware
-raise the question whether to supply more preloading/prerendering since we have more headroom

I can not estimate the possible options for more aggressive memory useage (profiles), but there are other requests covering that:
https://bugs.kde.org/show_bug.cgi?id=205301
https://bugs.kde.org/show_bug.cgi?id=185906
https://bugs.kde.org/show_bug.cgi?id=184196

Suggestion: 3 memory performance profiles, low for 512 MB or lower, normal for 512 to 1, 1.5 or 2 GB and aggressive for higher. The profiles should be packed with more preloading/prerendering capabilities, especially the normal and aggressive profile. It may make sense to offer checkboxes for very specific methods.

Reproducible: Didn't try
Comment 1 Richard Llom 2019-10-04 16:44:30 UTC 
Judging from the comments from bug 388854, this static memory limit is no longer applied. Instead it uses some smart algo and tries to maximize the use of free memory, with respect to the settings (low, normal, etc...)

(Unfortunately I couldn't find the documentation for the exact behavior.)

Closing as FIXED.