Description: When editing everything is fine. When hitting F5 several lines are not even drawn, bitmaps are pixelated, some off place. Steps to Reproduce: 1. Get my Document: https://joumxyzptlk.de/tmp/libreoffice/libre-office-pixelated-when-hitting-f5.pptx 2. Have a screen at 4K, 'cause I only have 4K and it might be related to that. 3. Hit F5 Actual Results: Pixelated view, even lines missing. Like it renders at 1024x768 instead of 4k (3840x2160). (Asked at https://ask.libreoffice.org/t/impress-slideshow-pixelated-images-why/121244 ) Result: https://ask.libreoffice.org/uploads/asklibo/original/3X/e/d/ed8f0c13897c048346aa2a7278753f179691f1bf.jpeg Annotated result: https://ask.libreoffice.org/uploads/asklibo/original/3X/3/a/3ab1e20161d5df0f54dd58ef048b858daab93d94.jpeg When editing everything is fine. Including export as jpeg PDF etc.: https://ask.libreoffice.org/uploads/asklibo/original/3X/6/6/66a146e71921072d6fd7c315179f814f3bf68b91.jpeg Expected Results: Sharp view. Reproducible: Always User Profile Reset: Yes Additional Info: Reproduced on Server 2022 and Windows 11 24h2, with two different builds. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 20348); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded GPU: Titan RTX (the one from December 2018, Turing generation) CPU: AMD Ryzen 5950x Version: 24.8.6.1 (X86_64) / LibreOffice Community Build ID: 051bf11303684a0a982c9966e8be766d0a9efbc7 CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded GPU: Intel integrated CPU: I5-6300U Switching OpenCL off did not change anything.
Created attachment 200517 [details] Document to test, pixelated when F5. Document to test, pixelated when F5.
Created attachment 200522 [details] What it looks likie with F5
Created attachment 200523 [details] Edit mode is fine
Created attachment 200524 [details] F5 view, but with remarks
Maybe related to https://bugs.documentfoundation.org/show_bug.cgi?id=92375. The line is a very reduced graphic. Select right-click original size. In normal mode, when changing the scale, in some of them, it becomes invisible.
Created attachment 200529 [details] Libre Office Pixelated 04 tried origina-size result (m_a_riosv)
(In reply to m_a_riosv from comment #5) > Maybe related to https://bugs.documentfoundation.org/show_bug.cgi?id=92375. > > The line is a very reduced graphic. Select right-click original size. > > In normal mode, when changing the scale, in some of them, it becomes > invisible. Erm, no, Result "original size" is: https://bug-attachments.documentfoundation.org/attachment.cgi?id=200529 but even when 1:1 would be used, i.e. as it is, the graphics would be too big. Lower resolution does not look good when printing. I fon't think it is related to the bug you link, since the file is fine. it is <bold>ONLY the F5 "presentation" view fails</bold>, like it renders those pixel-graphics i use at 960x720 instead of 3840x2160, while the rest is rendered as expected. The "960x720" is not just an accidental guess: When I do "Export as JPEG" it is the resolution offered. I enter 2160 as height (width is set to 2880 automatically), export it, and then it looks fine. The 960x720 jpeg version is low res, but at least all lines are drawn.
I judged the quality by the lines in the solar panels. Those are missing Repro with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fac8458e35620b9855cc6c68a9675159a849b65 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded also found in Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Mac OS X 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded fine with Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Mac OS X 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Bisect whether the presentation image is jagged Version: 7.3.6.0.0+ (x64) / LibreOffice Community Build ID: 8a3548eb859553a930a6120105cd30b3cc0ffeb3 author Miklos Vajna <vmiklos@collabora.com> 2022-08-03 commit 8a3548eb859553a930a6120105cd30b3cc0ffeb3 tdf#149943 vcl: fix pixelated PDF export and print for a rotated image The bugdoc has a barcode which looks good in Writer, but it's quite blurry in the PDF export result. This is a problem since commit dd4a67084853a030bf4b9f1f85d728620e0604a5 (vcl: avoid downscale && upscale in DrawTransformedBitmapEx(), 2019-10-08), where the motivation was to not downscale a bitmap in case it has a larger amount of pixels but a smaller logic size. This went wrong here and resulted in a blurry bitmap for a not so small image. Fix the problem by mostly reverting the above commit, because it's no longer necessary: 68549e00d5e23aa22bc974a8151d93cd948444b3 (vcl, BitmapEx transformed draw: special-case simple rotations, 2019-10-10) already made sure that the rotation case doesn't use scaling from the transform. testTdf128630 has been adapted to pass again (after manually verifying that the bugdoc export result is still OK), now the bad case there simply produces a smaller bitmap. (cherry picked from commit 7c94d7267bc8b5f43185204ab4953c4b188214bf) Change-Id: Ib28881c129a0cf037a96eecd065e5cadede97051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137743
Ah hm, then looks like this was working only in a limited window of time: originally it was broken, then got "fixed" by accident in 2019, but that had to be reverted due to a regression in 2022. So the next step would be to find a way that takes all 3 use-cases into account and come up with a solution that makes all 3 work at the same time. In other words, this only "worked" while introducing bug 149943, which is not something we want to re-introduce, I guess.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e81b948f90e66779e225d0dfb5e3ad1e6e80f289 tdf#166338 vcl: avoid unwanted downscale in DrawTransformedBitmapEx() It will be available in 26.2.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.
Tested today with the newest build I could see: https://dev-builds.libreoffice.org/daily/libreoffice-25-8/Win-x86_64@tb73-TDF/2025-09-27_05.24.35/ The fix did not make it into that build. I will retest next week with a newer build.
(In reply to Joachim Otahal from comment #12) > Tested today with the newest build I could see: > https://dev-builds.libreoffice.org/daily/libreoffice-25-8/Win-x86_64@tb73- > TDF/2025-09-27_05.24.35/ > The fix did not make it into that build. I will retest next week with a > newer build. Comment 11 said very clear that the bug was solved and published in 26.2 version, and you tested 25.8 version. What do you want to see in 25.8, when the change was published in a more recent version?
(In reply to BogdanB from comment #13) > (In reply to Joachim Otahal from comment #12) > > Tested today with the newest build I could see: > > https://dev-builds.libreoffice.org/daily/libreoffice-25-8/Win-x86_64@tb73- > > TDF/2025-09-27_05.24.35/ > > The fix did not make it into that build. I will retest next week with a > > newer build. > > Comment 11 said very clear that the bug was solved and published in 26.2 > version, and you tested 25.8 version. What do you want to see in 25.8, when > the change was published in a more recent version? Miklos Vajna wrote: "The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours." If you have a better hint where to get a newer or even a 26.2 test build I'll gladly test. For now that does not seem to be available, so I will have to recheck next week.
In your link test on master. Master is where all development is taking place.
(In reply to BogdanB from comment #15) > In your link test on master. Master is where all development is taking place. I thank you for your kind words and nice style of communication. https://dev-builds.libreoffice.org/daily/master/current.html , which gave me as newest build https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2025-09-26_03.28.27/LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64.msi Which is does not yet have that bugfix included. I will recheck next week, and report.
(In reply to Joachim Otahal from comment #16) Patch got committed on 2025-09-25 so it should be included in the master build from 2025-09-26_03.28.27
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/92cc08867f025cd62419f92e26a4d717575ac116 tdf#166338 vcl: avoid unwanted downscale in DrawTransformedBitmapEx() It will be available in 25.8.3. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/e33eb61588851de98ef275897ba7f9b68deae9c1 tdf#166338 vcl: avoid unwanted downscale in DrawTransformedBitmapEx() It will be available in 25.2.7. 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.
As for todays download of LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64.msi and LibreOfficeDev_25.8.3.0.0_Win_x86-64.msi I report "partially fixed". Most of the picture is sharp and therefore a big improvement. You can use the test case I opened the bug with. Resolution here: 3840x2160 on Server 2025/Win11 with Nvidia RTX and Server 2022 on a laptop with intel gfx. Pixelation still visible at the first red "corner" cable at the Growatt, and some of the MC4-plugs. Some of the positions are not right as well, compared to the normal editing view, and some of the "cables" still vanish. (The "Ost" text does not look right too, but that is in edit mode as well. So please ignore that - I suspect a font mixup reason since OS is fresh installed.) Screenshots are avail if you need them. Thank you for keeping on with that bug!
(In reply to Joachim Otahal from comment #20) > Pixelation still visible at the first red > "corner" cable at the Growatt, and some of the MC4-plugs. True, not related to the regression fixed here > Some of the > positions are not right as well, compared to the normal editing view, and > some of the "cables" still vanish. True, but also pre-existing problem > (The "Ost" text does not look right too, but that is in edit mode as well. Recently introduced bug --- So seems better to keep this one closed and to open 3 separate bug reports for the other issues
> So seems better to keep this one closed and to open 3 separate bug reports for the other issues Agreed. One way you can keep developer motivation is to have focued bugreports: if you have 4 related problems, please file a separate report for all 4. I think the specific regression problem reported here is fixed, I suggest to close this again and have follow-up reports for your related problems. Thanks.
OK, no reply in a week, let me close it and please open followup reports for the related problems. Thanks.