Description: Insert a hi-res HiDPI image into LibreOffice Writer. Image is blurrier than it should be. Note, if I insert it into Calc or Draw, it looks great. Steps to Reproduce: Insert HiDPI image such as in attached document Actual Results: Image is blurrier than it should be Expected Results: Image should be just as crisp as the original screenshot scaled down to the same size. Reproducible: Always User Profile Reset: No Additional Info: Standard Arch Linux Gnome 3 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Created attachment 139986 [details] Sample document with big image
Created attachment 139987 [details] Blurry LibreOffice image in screenshot
Created attachment 139988 [details] Screenshot with crisp original image on top.
Repro, but only with GTK3 Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 856c57f20f9b07c686a854e0ccbb6ee3b0ee4791 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on March 7th 2018
I tried it out on KDE / Plasma and also noticed that high-res bitmaps look better there.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Yes, this still reproduces in LibreOffice 6.2.2.2
This bug is no longer reproducible in Version: 6.2.0.3 Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 1; OS: Linux 5.0; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Changing status to RESOLVED WORKSFORME
(In reply to Babak Razmjoo from comment #8) > This bug is no longer reproducible in > Version: 6.2.0.3 > Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 > CPU threads: 1; OS: Linux 5.0; UI render: default; VCL: x11; > Locale: en-US (en_US.UTF-8); UI-Language: en-US > Calc: threaded > Changing status to RESOLVED WORKSFORME You are running without any particular VCL backend (x11). You should test with gtk3.
I imagine we've scaled the image down and then upscaled that result up back again
The problem is in drawinglayer/source/processor2d/vclhelperbufferdevice.cxx impBufferDevice::paint where the HiDpi-supporting OutputDevices are mergeded together to form a bitmapex (non-hidpi) and then blitted the final outputdevice so gets blurry as it goes through a bitmapex
I think for this common case we can avoid the transparent outputdevice thing, though for the general case we need a different approach or to allow outputdevices to be combined directly without intermediate bitmaps
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b1f961e3a459d2772f12da556ab74fa635d6a46a%5E%21 tdf#115843 avoid using transparent virtualdevice when 100% opaque It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
presumably there exists some edge cases where it can appear, but for the normal experience the above seems sufficient to avoid this problem
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/6affe1576e34d6bc111d1db38416492375fd5fcc%5E%21 tdf#115843 avoid using transparent virtualdevice when 100% opaque It will be available in 6.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.