Thumbnail size limited in settings

[Dorian Scholz]

In Settings->Graphics->General the option "Thumbnail size" can only be increased to 300px.
On modern high-density screens this produces quite a small thumbnail.
I was able to fix it by just changing the setting "thumbnailSize" in the config file in "~/.config/qpdfview/qpdfview.conf".
This workaround is fine for me, but it should be easy to fix the settings dialog for the next release so people with high-density screens can adjust this more easily.

P.S. It would be even better to dynamically scale the thumbnails depending on the width of the dock window, but this is probably more work...

[Adam Reichold (adamreichold)]

Hello Dorian,

I can surely increase the maximum value for this setting. After all this is just to prevent a very large scale factor which will consume enormous amounts of memory leading to intensive swapping. What do you think would be a sensible value? I'd propose 900 px.

The automatic scaling should of course be possible but there is a technical issue: The document views only create a graphics scene whereas its view is controlled by the main window (to conserve memory). Hence we would need to wire the size change in directly which could get messy. But I will look into it, maybe implementing it as a special value of 0 for the thumbnail size...

Best regards, Adam.

[Dorian Scholz (dorianscholz)]

Hi Adam,

thanks for the very prompt response!

A decent value for the maximum thumbnail size pretty much depends on the physical resolution of your screen (DPI/PPI) and you personal preference of physical size of the thumbnail on the screen.
On my 15.4" 1920x1080 laptop I have 143 DPI:
(1920**2 + 1080**2)**0.5 / 15.4 = 143.0

As thumbnail size I prefer 600px which displays the thumbnails about 4.2 inches high::
600 / 143.0 = 4.2

Newer laptops have even higher DPI values of up to 282 from what I found on:
http://www.lightandmatter.org/2014/general-photography-articles/computers-tech/best-4k-and-high-ppi-laptops-for-photo-editing-2014/

So to get my preference of 4.2 inch thumbnail size on a 282 DPI laptop the pixel size would need to be 1184px:
4.2 * 282 = 1184.4

As the DPI will surely grow even further and someone's preference for thumbnail size might even be bigger than mine, I would recommend using a value higher than this.
Maybe 1600px sounds like a nice value for now, but this might change again in a year or two...

But is there any need to restrict the value at all?
Or could it just have a tool tip warning that very large sizes will decrease performance?

As for the dynamic size change:
Could the thumbnail view simply be a second PDF view with automatically scaled pages to fit the width?
Or would that be too much of a performance overhead?

Cheers,
Dorian

[Adam Reichold (adamreichold)]

Hello again,

I would like to limit as we limit the maximum scale since the application could become unresponsive if the size is chosen too large, especially since one can always tweak dangerous settings via the configuration file (as for example via the auto-refresh timeout or the tile size where this is the only way). For now I adjusted the maximum available in the settings dialog to 1800 px but also implemented the dynamic adjustment (if one chooses the special value zero) which should fit this to the width or height of the viewport depending on the dock widget orientation. Testing of the linked is appreciated.

Best regards, Adam.

[Dorian Scholz (dorianscholz)]

Hey Adam,

this is a great improvement!
I've tested it in horizontal and vertical layout and it works great!
I was able to make the thumbnails not fit in the view though by resizing the dock really fast.
Not sure if this can be avoided easily, but it is more of a cosmetic problem, since resizing at normal speed works just fine.

One thing that is especially nice with your change is, it also "fixes" another issue that was bothering me before in the fixed size layout.
In documents with mixed landscape and portrait pages they were not all the same width in vertical (or height in horizontal) dock layout.
But rather had the fixed thumbnail size as height for portrait and as width for landscape pages, making the dock never fit them all perfectly...

Maybe you want to add this change to the fixed thumbnail size code as well?
I guess the problem is just the use on qMin in documentview.cpp:2531 compared to the if/else switch based on m_thumbnailsOrientation which you implemented in the dynamic scaling part.

Thanks again for this really fast fix!

Cheers,
Dorian

[Adam Reichold (adamreichold)]

Hello Dorian,

if I do not find any more problems besides the minor miscomputations because of the size of the scroll bars, I will probably merge this tomorrow so it becomes part of any daily builds.

Concerning the uniform width/height, I do not think I want to change this, as the idea of the scaling method was to show as much as possible (i.e. to have the largest possible scale factor) without any dimension exceeding the thumbnail size. Meaning to fill as much as possible of a square of width equals the thumbnail size. With the change you suggest, landscape pages in a vertical thumbnails view would have a smaller scale factor than portrait ones, whereas they now have a pretty much uniform scale factor.

So you can fit them all, it is just that some will not use all of the horizontal/vertical space as they are limited by their vertical/horizontal size. Depends on how you look at it. :-)

Best regards, Adam.

[Dorian Scholz (dorianscholz)]

Hey Adam,

sure, there is no need to change the behavior for the fixed thumbnails.
I'm quite happy with the dynamically scaled ones, so I'll stick with that anyhow.

I just usually have the dock in vertical mode and documents with mostly portrait pages.
And sometimes there is the odd landscape page in such a document.
On the fixed size mode this made the width of my thumb view to narrow and the scrollbars appeared, making also the portrait pages not fit anymore...
But thats history now - long live the dynamically scaled thumbnails ;-)

Cheers and thanks for qpdfview,
Dorian

[Adam Reichold (adamreichold)]

The branch is now merged and should become available via the daily builds and such...