Bug 401339 - presentation: odd scaling/anti aliasing
Summary: presentation: odd scaling/anti aliasing
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-23 16:19 UTC by Dr. David Alan Gilbert (rh)
Modified: 2019-06-22 15:21 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.7.3


Attachments
page as rendered by okular (119.70 KB, image/png)
2018-11-23 16:19 UTC, Dr. David Alan Gilbert (rh)
Details
same page rendered by evince (182.01 KB, image/png)
2018-11-23 16:20 UTC, Dr. David Alan Gilbert (rh)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dr. David Alan Gilbert (rh) 2018-11-23 16:19:06 UTC
Created attachment 116479 [details]
page as rendered by okular

SUMMARY

With the attached presentation I'm seeing two odd things:
  a) In presentation mode it's displaying really bad bitty fonts; as if it's rendered for way too low a resolution and then upscaled
  b) Sometimes I'm seeing it skip pages - it's not eveyr time but it's weird and page up/down will skip pages altogether.

STEPS TO REPRODUCE
1. Load attached presentation
2. shift-ctrl-p for full screen
3. page up/down

OBSERVED RESULT
a) The whole rendering is awful - as if it's to much too low a resolution (see attached screen shots)
b) Sometimes the page up/down skips pages

EXPECTED RESULT
No skipped pages, and see the attached screen shot from evince

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: okular-18.08.1-1.fc29.x86_64 on Fedora 29 - shows as 1.5.1 in about
(available in About System)
Running under xfce
Qt Version: qt5-qtbase-5.11.1-9.fc29.x86_64

ADDITIONAL INFORMATION
I'm running a dual head setup, with an internal 1920x1080 display on the laptop and an external 3840x2160 uHD display.  The document is being displayed on the external uHD.
Comment 1 Dr. David Alan Gilbert (rh) 2018-11-23 16:20:09 UTC
Created attachment 116480 [details]
same page rendered by evince
Comment 2 Dr. David Alan Gilbert (rh) 2018-11-23 17:47:09 UTC
The pdf is a bit too big to upload; however you can get it:
https://schd.ws/hosted_files/kvmforum2018/a8/ramcomplexity.pdf
Comment 3 Albert Astals Cid 2018-11-23 22:09:29 UTC
Do you have this problem if you display it on the main screen?
Comment 4 Dr. David Alan Gilbert (rh) 2018-11-26 16:32:46 UTC
(In reply to Albert Astals Cid from comment #3)
> Do you have this problem if you display it on the main screen?

Hmm; no I think it's fine on the main HD screen.  I think the odd thing is that the rendering on the uHD screen seems to be much worse than even HD.
Comment 5 Albert Astals Cid 2018-11-26 22:27:10 UTC
Probably getting confused by two screens with different pixel densities.
Comment 6 Dr. David Alan Gilbert (rh) 2018-11-27 10:18:08 UTC
(In reply to Albert Astals Cid from comment #5)
> Probably getting confused by two screens with different pixel densities.

Possibly; for reference the physical devices are the ~15" LCD HD in the T530 laptop, and a ~28" LCD uHD in the external Dell S2817Q monitor.
xrandr says:

Screen 0: minimum 320 x 200, current 5760 x 2160, maximum 8192 x 8192
LVDS-1 connected 1920x1080+0+1080 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080     60.02*+  60.01    59.97    59.96    50.03    59.93  
   1680x1050     59.95    59.88  
   1400x1050     59.98  
   1600x900      59.99    59.94    59.95    59.82  
   1280x1024     60.02  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1280x800      59.99    59.97    59.81    59.91  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected 3840x2160+1920+0 (normal left inverted right x axis y axis) 621mm x 341mm
   3840x2160     29.98* 
   1920x2160     59.99  
   2560x1440     59.95  
   2048x1280     59.92  
   1920x1080     60.00    60.00    50.00    59.94    24.00    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00    50.00  
   720x480       60.00    60.00    59.94    59.94  
   640x480       75.00    60.00    59.94    59.94  
   720x400       70.08
Comment 7 Dr. David Alan Gilbert (rh) 2018-12-07 19:48:10 UTC
The same thing happens on my other machine, with a similar F29 install; it's a desktop with a Radeon, the same uhd monitor and and a HD monitor.
So whatever the problem, it's not specific to the graphics card or the exact config.
Comment 8 Dr. David Alan Gilbert (rh) 2018-12-21 00:33:39 UTC
I built with debug and think I've tracked the problem down to the use of the tilemanager; and I think it's interacting with images rendered for previews/thumnails, so that it's using those small images.

I noticed that document.cpp DocumentPrivate::snedGeneratorPixmapRequest has a 8MPixel limit and says:
'If the requested area is above 8000000 pixels, switch on the tile manager'

well, uHD is 3840x2160=8294400 pixels - so that triggers.
If I bodge that limit to 10M my problem goes away.

So then I added a debug just under the 'fill the tiles manager with the last pixmap' around line 1342  after the 'if (pixmap)'

and I see:
org.kde.okular.core: Start using tiles on page 11 (3745x2160 px);
org.kde.okular.core: tilesManager existing pixmap width=474 height=273

that 474x273 is the size of the preview shown in the main okular window in 'Overview' mode (and I'm running 9 slides visible).

So you *might* not notice this if you were running full-page in your non-presentation window; however even then I managed to trigger it non-repeatably; and I think what's happening in that case is that if in the main window I have:
   a) Full size previews on my HD monitor (with menus/thumbnails/borders a bit less than 1920x1080) - OK they look a bit fuzzy when scaled to uHD but many might not notice or complain
   b) If you get unlucky you've not looked at the page in the preview, but you DO* have the thumbnail from the thumbnail side bar, and that's abysmal resolution; but it's the last one you've got so you scale it up.

so I think the if (pixmap) test for reusing an existing pixmap needs to be smarter somehow;  maybe it only uses the existing pixmap if the pixmap size actually fully matches? Or maybe you have to give it some slack for cases where the scaling has to round?

e.g. if you weren't running previews then p
Comment 9 Albert Astals Cid 2019-06-22 14:44:35 UTC
Git commit f4a883ea5d0a3b9e65244264503ea1ccd8c58cc9 by Albert Astals Cid, on behalf of Dr. David Alan Gilbert.
Committed on 22/06/2019 at 14:43.
Pushed by aacid into branch 'Applications/19.04'.

Partial fix for high res displays

Summary:
On high res displays we end up using
the tile manager on single pages, that doesn't work
(for reasons that aren't yet clear) - but it
doesn't make sense if we most of the page anyway.

Reviewers: #okular, aacid

Subscribers: okular-devel

Tags: #okular

Differential Revision: https://phabricator.kde.org/D20882

M  +5    -2    core/document.cpp

https://invent.kde.org/kde/okular/commit/f4a883ea5d0a3b9e65244264503ea1ccd8c58cc9