Created attachment 95033 [details]
Snapshot of open file with 4.1 version

Created attachment 95034 [details]
Snapshot of open file with 4.2 version

It’s not like “LibO 4.2 displays bitmap at lower resolution”. The bitmap is low-resolution in both screenshots, the only change is the interpolation method used to upscale it.

Yes, right...
However, the upscaling used in 4.1 is much more satisfactory.
I have changed the bug title accordingly.

For me it's not a bug. What is important is that the image looks smooth during the slideshow and at the scale of the slideshow. If it does not look perfect at 200% is not a problem because you don't use the picture at this scale.

Best regards. JBF

I cannot understand if you believe that now it is better than it was in 4.1 and why.

To me it is definitely worsened. The image looks grainy at any scale (the 180% in the screenshot was just to get only the picture in the screenshot and I initially noticed it at the fit page zooming level). This can be checked by opening the test file. As such it is distracting and transmitting to the user the impression that he/she is doing a mediocre job even if this is not the case.  Unless there is a huge performance penalty in doing things as they were done in 4.1, I really cannot see why this should not be a regression.

Furthermore it is weird that if you erase and re-import the picture then it looks better.

(In reply to comment #6)
> I cannot understand if you believe that now it is better than it was in 4.1
> and why.

Because I do not see any difference when the zoom level ≤ 100% and in slideshow mode.

Best regards. JBF

Created attachment 95493 [details]
Issue at 75% zoom

I see the issue at 85% zoom with LibO 4.2 (see attachment - sorry I wrote 75 in the attachment title instead of 85). And this with a low res screen. With the laptop with a full-HD screen I see a difference even at 65%.

I find it disturbing, because it inconsciously forces me to test every slide in presentation mode to be sure that at least in this mode things will look right and this is a waste of time. And I find it disturbing because things look bad when I work on them with other people, making me appear as the one who is chosing a second class tool (make a guess about what they suggest to move to).

But this does not really matter. Even if the misrendering was only evident at a 1000% zoom, since LibO 4.1 was not showing any misrendering at any zoom level (which is quite evident) may I ask again why you think that the 4.2 behavior is better and should be kept?

There can be a good reason, but otherwise please say that this is a minor issue (which already is debatable as many think that reproducible regressions are never minor), or low priority, but not that it is not a bug.

Also note that I may be a little more tenacious than average user here. I'm sure that you are in perfect good faith, but consider that someone else would have already been turned down, mentally classifying the action of having opened a bug report with a reproducible test case as a waste of time.

Scaling of bitmaps has changed indeed in 4.2. CC-ing Kendy.

Looks like it's back to the 4.1 style, so WFM.

Win 7 64-bit Version: 4.4.0.0.alpha1+
Build ID: b7d8a58ff2698ffc6e22943f64aa97c5ea253bd9
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-05_00:40:38

How is this resolved? Just tripped over this bug, 2 slides showing differences in processed images look fine in edit mode then the subtle difference disappears in slide show mode making the slides look the same.

(In reply to franco.broi from comment #12)
> How is this resolved? Just tripped over this bug, 2 slides showing
> differences in processed images look fine in edit mode then the subtle
> difference disappears in slide show mode making the slides look the same.

Apologies, this is Linux-only and still reproducible. Setting to NEW.

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: a55adb16ece70360c88342ca008d5a9d5b9d5b52
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-18_22:04:40

I can no longer reproduce this issue in

Version: 5.3.0.0.alpha0+
Build ID: ae3ec79354f7b4967e736c6a4cd7c08fc52e2b7d
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

thus, closing this as RESOLVED WORKSFORME

My observations with LO 5.2.2.2 / Windows 7:

-with OpenGL enabled, attached file looks like "Snapshot of open file with 4.2 version" when zoomed in,
-with OpenGL disabled, attached file looks like "Snapshot of open file with 4.1 version" when zoomed in.

I'm assuming it's not fixed, and the bug is now related to OpenGL rendering.

No, it's not related to OpenGL rendering. The interpolation for 220% zoom is still the same as with 4.2 / attachment 95034 [details]

75% is interpolated smoothly, but when you go further in, the edges look glitchy.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: ff2a399b61f34f7920e594e8cbb6c19045b24956
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 7th 2016

(In reply to Buovjaga from comment #17)
> No, it's not related to OpenGL rendering. The interpolation for 220% zoom is
> still the same as with 4.2 / attachment 95034 [details]

Ok, then it's different in Windows and in Linux.
Possibly the original issue in Linux, and something introduced by OpenGL rendering in Windows.

so what about bug 86675 ?

Ok, I've been able to bibisect this in bibisect-42max ( although it looks much better in master for me now)

Regression introduced by 45a8eaf9c55f2686f69118641d8a8992a86dfe31 which is the same as in bug 80385.

Closing this bug as RESOLVED DUPLICATE.

@Sergio: Thank you very much for reporting this bug.

*** This bug has been marked as a duplicate of bug 80385 ***