https://bugs.kde.org/show_bug.cgi?id=431945

mourgos <papazoglou.anes...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |papazoglou.anes...@gmail.co
                   |                            |m

--- Comment #6 from mourgos <papazoglou.anes...@gmail.com> ---
(In reply to Tiar from comment #5)
> Looks like it's inevitable: performance is more important... you're welcome
> to make a MR, but please:
> 1) add a comment explaining why preview.png is used instead of
> mergedimage.png (so no one else makes the same mistake again),
> 2) keep other changes; for example the devicePixelRatioF() stuff (it keeps
> it looking at least somewhat nice on 4k screens). (I'm afraid the pixel art
> won't look good there anyway, so it might be a good idea to remove that part
> that scales them up using FastTransformation; it will be blurred terribly
> anyway, unfortunately... SmoothTransformation at least will have only one
> kind of artifacts).
> 3) It would be good if you checked if after your changes the pages in the
> page viewer are still rendered nicely with high resolution.
> 
> Thank you :)

I have created a (quite minimal) MR:
https://invent.kde.org/graphics/krita/-/merge_requests/920

I just changed the source image for the thumbnails in the docker, so the page
viewer is unaffected as far as I can tell. Unfortunately I don't own any HiDPI
displays, so I wouldn't be able to tell the difference if HiDPI support
regressed. I don't anticipate the change to break anything, but if anyone with
a HiDPI monitor could double check it would be greatly appreciated.

As a future improvement, I think it would be possible to have higher resolution
thumbnails if we allowed some preprocessing and additional storage in the comic
project folder. We could generate dedicated higher res previews (512px) from
the merged image every time we detected a change in a .kra file, and store it
in a dedicated folder (e.g. <project_root>/thumbnails). This could then be used
to populate the thumbnail list instead of loading from the .kra files.

I did not attempt to do that yet, because it would add quite a bit of
complexity to do it right, and I first wanted a fix for the current problem.
The main issue is that there is a nasty corner case when the .kra file gets
modified without loading the project in the comic manager first, which can lead
to stale thumbnails (this is fixable but a proper solution is complex). That
and the fact that we'd need to create an additional folder on disk, which might
be undesirable. However, if you are OK with the idea I could try to implement
that once I get some free time.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to