Bug Hunting Session
Bug 75715 - EDITING: REGRESSION: LibO 4.2 displays low resolution bitmap with poor upscaling wrt 4.1
Summary: EDITING: REGRESSION: LibO 4.2 displays low resolution bitmap with poor upscal...
Status: RESOLVED DUPLICATE of bug 80385
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.2.2.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: possibleRegression
Depends on:
Blocks: OpenGL
  Show dependency treegraph
 
Reported: 2014-03-03 14:41 UTC by sergio.callegari
Modified: 2016-10-11 09:30 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
test document (77.08 KB, application/vnd.oasis.opendocument.presentation)
2014-03-03 14:41 UTC, sergio.callegari
Details
Snapshot of open file with 4.1 version (519.71 KB, image/png)
2014-03-03 14:43 UTC, sergio.callegari
Details
Snapshot of open file with 4.2 version (213.53 KB, image/png)
2014-03-03 14:47 UTC, sergio.callegari
Details
Issue at 75% zoom (197.72 KB, image/png)
2014-03-10 10:13 UTC, sergio.callegari
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2014-03-03 14:41:45 UTC
Created attachment 95032 [details]
test document

Problem description:

Document including a png image is displayed just fine for edinting in LibO 4.1, but shows a low resolution bitmap with 4.2

Steps to reproduce:
1. open test file with both versions
              
Operating System: Ubuntu
Version: 4.2.2.1 rc
Last worked in: 4.1.5.3 release
Comment 1 sergio.callegari 2014-03-03 14:43:39 UTC
Created attachment 95033 [details]
Snapshot of open file with 4.1 version
Comment 2 sergio.callegari 2014-03-03 14:47:18 UTC
Created attachment 95034 [details]
Snapshot of open file with 4.2 version
Comment 3 Adolfo Jayme 2014-03-06 05:45:18 UTC
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.
Comment 4 sergio.callegari 2014-03-08 17:52:17 UTC
Yes, right...
However, the upscaling used in 4.1 is much more satisfactory.
I have changed the bug title accordingly.
Comment 5 Jean-Baptiste Faure 2014-03-08 23:07:33 UTC
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
Comment 6 sergio.callegari 2014-03-09 23:30:49 UTC
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.
Comment 7 Jean-Baptiste Faure 2014-03-10 05:22:07 UTC
(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
Comment 8 sergio.callegari 2014-03-10 10:13:10 UTC
Created attachment 95493 [details]
Issue at 75% zoom
Comment 9 sergio.callegari 2014-03-10 11:01:32 UTC
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.
Comment 10 Andras Timar 2014-03-14 07:48:16 UTC
Scaling of bitmaps has changed indeed in 4.2. CC-ing Kendy.
Comment 11 Buovjaga 2014-11-05 07:37:09 UTC
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
Comment 12 franco.broi 2014-11-20 01:51:07 UTC
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.
Comment 13 Buovjaga 2014-11-20 06:21:19 UTC
(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
Comment 14 Robinson Tryon (qubit) 2015-12-09 18:29:07 UTC Comment hidden (obsolete)
Comment 15 Xisco Faulí 2016-10-08 16:25:36 UTC
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
Comment 16 Aron Budea 2016-10-09 12:25:22 UTC
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.
Comment 17 Buovjaga 2016-10-09 12:59:25 UTC
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
Comment 18 Aron Budea 2016-10-09 15:52:22 UTC
(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.
Comment 19 Cor Nouws 2016-10-11 09:09:14 UTC
so what about bug 86675 ?
Comment 20 Xisco Faulí 2016-10-11 09:30:21 UTC
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 ***