Bug 141832 - Using dummy version of images (thumbnails) for faster editing
Summary: Using dummy version of images (thumbnails) for faster editing
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Image-Compression Options-Dialog-Writer
  Show dependency treegraph
 
Reported: 2021-04-22 15:04 UTC by csongor
Modified: 2021-05-17 08:30 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description csongor 2021-04-22 15:04:44 UTC
I frequently work with Writer documents that are 10-100 pages long and have several high-resolution images in them. After adding some pictures to the document, LO becomes very slow and uses a lot of computer resources (memory and CPU). 

It would be nice to change the Tools -> Options -> LibreOffice Writer -> Display -> [_] Images and objects checkbox. 

Now it is a simple checkbox, but I would like to have these radio buttons instead:
(o) Show maximal resolution
(o) Show low resolution (10 DPI)
(o) Do not show 

When the low-resolution setting is active, LO would generate the thumbnails and store them in cache (memory or disc). During the editing phase, the thumbnails would be used, but before printing or exporting, it would switch to the original resolution versions.
Comment 1 Dieter 2021-05-08 04:31:57 UTC
Csongor, thank you for the report. I could find two bug reports that suggest something similar: bug 34133 and bug 77407. Could you please check, if your report is a duplicate of one of them. Thank you.
=> NEEDINFO
Comment 2 V Stuart Foote 2021-05-08 13:43:14 UTC
Both the see also bugs are about changing the resolution of the images. Suggestion here is to refactor the current wire frame view to provide three "non-destructive" choices for working with document canvas.

Currently we get images/pictures visible (at resolution) or suppressed (just the wire frame). The new "mode", with change to the UI, would be to display the image as a low resolution placeholder during editing--but not changed for printing or publishing.  The oposite of the see alsos which are destructive.
Comment 3 csongor 2021-05-09 12:17:41 UTC
(In reply to V Stuart Foote from comment #2)

> Both the see also bugs are about changing the resolution of the images.
> Suggestion here is to refactor the current wire frame view to provide three
> "non-destructive" choices for working with document canvas.
> 
> Currently we get images/pictures visible (at resolution) or suppressed (just
> the wire frame). The new "mode", with change to the UI, would be to display
> the image as a low resolution placeholder during editing--but not changed
> for printing or publishing.  The oposite of the see alsos which are
> destructive.

Yes, this is totally correct. My request (this ticket) is not the duplicate of the two tickets mentioned by @Dieter.
Comment 4 V Stuart Foote 2021-05-09 15:04:43 UTC
+1, a reasonable enhancment, but suspect a fair bit of dev work to "protect" the images when swapping in the low resolution placeholders (rather than the existing wireframe methods).

@Tomaž, what do you think?
Comment 5 Heiko Tietze 2021-05-10 09:42:09 UTC
Yes, would be nice to have. Wouldn't stick to the 10dpi and definitely not add this to the label, though.
Comment 6 Tomaz Vajngerl 2021-05-14 13:27:21 UTC
(In reply to V Stuart Foote from comment #4)
> +1, a reasonable enhancment, but suspect a fair bit of dev work to "protect"
> the images when swapping in the low resolution placeholders (rather than the
> existing wireframe methods).
> 
> @Tomaž, what do you think?

Well yes, this is not a new idea (I have various ideas around how to accelerate images), however it is not that simple. The most important thing is that you sometimes want to use a low-res placeholder and then in another case it would be a disaster if you would not use the full-res bitmap. For example rendering on screen, but then PDF export of the document.
Comment 7 csongor 2021-05-15 03:43:35 UTC
(In reply to Tomaz Vajngerl from comment #6)
> you sometimes want to use a low-res placeholder and then in another
> case it would be a disaster if you would not use the full-res bitmap. For
> example rendering on screen, but then PDF export of the document.

Yep, that's why I wrote in the original message:

> During the editing phase, the thumbnails would be used, but 
> before printing or exporting, it would switch to the original 
> resolution versions.


> I have various ideas around how to accelerate images

Do you mean something else than using thumbnails? What ideas do you have? It sounds interesting.
Comment 8 Heiko Tietze 2021-05-17 07:53:10 UTC
(In reply to Tomaz Vajngerl from comment #6)
> ...you sometimes want to use a low-res placeholder and then in another
> case it would be a disaster if you would not use the full-res bitmap...

Reminds me on Internet in the modem era. How about loading the full-res bitmap on click? Or better including some modifier such as Alt.
Comment 9 csongor 2021-05-17 08:30:16 UTC
(In reply to Heiko Tietze from comment #8)
> Reminds me on Internet in the modem era. How about loading the full-res
> bitmap on click? Or better including some modifier such as Alt.

Oh, those nice times. :D 

The click also can work but there needs to be a way to 
revert it. Once I checked how the detailed image looks, I may want to go back to the dummy version in order to save resources. 

Btw., I call it "dummy" version instead of "thumbnail" to emphasize that the dimension of the image (in centimeters) should not change, just the number of the pixels. Say, if I insert a 17x25 cm bitmap then I want to see it in this size (spanning from margin to margin in both directions on the A4 page), even if the dummy version is turned on. I just want to represent it with <10k pixels rather than millions of them.