This is not a bug but a performance improvement request that could help a lot. I am authoring a users' manual for our product which includes lots of images (both vectors and 300dpi bitmaps). To keep the file size under check and to reduce the file saving / loading time all those images are inserted as 'linked' images with the source images kept in the same folder. While navigating the document using the scroll bar or mouse wheel it gets stuck at those pages where the images are present while Writer loads them. Its also not uncommon to see the image link / 'Read Error' in the place holder alternating in the place-holder area while the image loads. Even when loaded, sometime the page needs to be zoomed in / out to get the image visible. I was wondering if it is possible to cache a low resolution version of the image so that navigational performance is improved. I believe it is Adobe - InDesign where you have an option to display a very ugly low resolution version of the document while to make it. Then once your done you could turn it off or even if you don't the PDF or prints you take from the document will contain the original resolution of the images. Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: en-US (en_US); Calc: CL
try use View > Images and Charts to disable shows all images in your document. And if you want add new functional in LibreOffice, then change heading of bug to (example) "Add possible to cache a low resolution version of the image so that navigational performance is improved" and change Importance to medium-enhancement
In reply to Comment 1 Using 'View > Images' to hide the images works but it's not possible to author the document when you have a large documents with a lot of pictures.
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #3) > A new major release of LibreOffice is available since this bug was reported. > Could you please try to reproduce it with the latest version of LibreOffice > from https://www.libreoffice.org/download/libreoffice-fresh/ ? > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the latest version. No point as this is an enhancement request. Let's rather show this to UX team.
If you load a 300dpi image when the screen is only capable of 96dpi it has some overhead. However, that means you have to store the low-resolution cache data somewhere and that contradicts the linked image idea, doesn't it? Any idea, Tomaz?
Well, the idea I have is to implement mip-map algorithm directly into our graphic handling. Which means, that we would create (on demand) many scaled down versions of the same image and store them to the disk, then choose which one we need depending on how scaled the image we want. For example: if the original image is 4000x3000 and in the document it needs to be scaled to 400x300, we would choose a 4x scaled down version (1000x750) and scale that down to 400x300. Choosing a smaller version of the image would immediately result in a speed-up. The cool thing is also that if there is no demand for the original 4000x3000 version (and it most likely there probably wouldn't be if you look at the image at normal zoom levels) it could be removed from the memory, which means LO would use less memory in general and handle a lot of loaded images much much better. Previously, something like this was not possible but thanks to image handling rework this should n't be hard to do. Now, to this request. When we have the basic algorithm implemented, it shouldn't be hard to change it such way that we don't choose a full-res image, if that one is over a certain threshold and make that configurable so the users can choose whatever quality/speed ratio they prefer (from 3-4 options).
(In reply to Tomaz Vajngerl from comment #6) > When we have the basic algorithm implemented, it > shouldn't be hard to change... Sounds great. Can I/you assign this ticket to you?
I'm OK with assigning only when I'm actively working on a bug (i.e. will solve the bug in the near future), but for this bug this is not the case.