Bug 134352 - Skia engine leaves scaled raster images far blurrier than does hardware rendering
Summary: Skia engine leaves scaled raster images far blurrier than does hardware rende...
Status: RESOLVED DUPLICATE of bug 134129
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.0.0.0.beta1+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Skia
  Show dependency treegraph
 
Reported: 2020-06-28 04:50 UTC by xordevoreaux
Modified: 2020-07-01 17:58 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
LO Draw file used to create the output for this bug. (297.98 KB, application/vnd.oasis.opendocument.graphics)
2020-06-28 04:50 UTC, xordevoreaux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description xordevoreaux 2020-06-28 04:50:17 UTC
Description:
This https://i.imgur.com/0NP4IJ8.png is three exports from the same LO Draw document.

The top image is output using hardware rendering with anti-aliasing.
The middle image is output using SKIA without anti-aliasing.
The bottom image is output using SKIA with anti-aliasing.

I have always been used to the output quality of the top image. I'm quite surprised of the level of degradation in scaling SKIA puts out.

Steps to Reproduce:
1. Launch LO Draw
2. Import or copy/paste a large raster image
3. Scale the image down until it's about 1/4 to 1/5 the original size
4. Export a PNG three times using different output methods
4a. hardware with anti-aliasing
4b. Skia with anti-aliasing
4c. Skia without anti-aliasing

Actual Results:
Only the hardware rendering option produced a crisp image. Skia-rendered scaled raster images are unacceptably blurry

Expected Results:
The skia output option should produce as equally crisp images as hardware rendering.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.beta2 (x64)
Build ID: 1c213561a365b5666167321de68c9977500c9612
CPU threads: 8; OS: Windows 10.0 Build 20152; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 1 xordevoreaux 2020-06-28 04:50:55 UTC
Created attachment 162465 [details]
LO Draw file used to create the output for this bug.
Comment 2 Telesto 2020-06-28 09:19:36 UTC
The picture quality with GDI export is already horrific. And looks like Skia is only solving the quality lack by applying anti-aliasing. 
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: de-DE (nl_NL); UI: en-US
Calc: CL

Surely a bug, but not by Skia as such
Comment 3 Telesto 2020-06-28 09:59:59 UTC
This is probably caused by old, old (evil) bug. FWIW: Compare PDF export with PNG (PDF always crisp) with PNG being only good at smaller sizes

Found in
7.1
6.4
6.0
4.4.7.2
4.2
4.0
3.5.7.2

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Which did remember me of bug 132590 comment 10

SVG: 
- Border look the same as in 7.0 PNG
- Bad quality export
- Dimensions totally (17,39cm x 27,70 cm)
PNG:
- Looks the same as in 4.4.7.2 
- Has the same oversized issue (12,60x10,85) Expected: 12,25 x 12,50)
- Bad quality export
BMP: 
- Proper size
- Proper dimensions
- Bad quality
SVM
- Oversized (12,60x10,85)
- Proper quality 
- Borders OK
JPG
- Again different dimensions: 12,62cm x 10,87cm
- Bad quality export
- Borders look OK

So SVM export (dropped since....) used another code path not messing with image quality while re-compressing. Same for PDF export.. Also fine..
Comment 4 xordevoreaux 2020-06-30 12:00:10 UTC
So with this block https://bugs.documentfoundation.org/show_bug.cgi?id=129062
that has been assigned to this bug, does that mean I need to start an education campaign for all of my users of my templates to tell them to use hardware rendering with 7.x if they expect to have sharp/crisp output of their work?  And any ETA when this logjam will get cleared?
Comment 5 xordevoreaux 2020-06-30 12:12:22 UTC
Okay, I looked up the definition of a block, and it's the opposite of what I thought it as. The other bug list won't be considered resolved until all the bugs on it are. Got it.

I still think, at least for now, that I need to add a warning on my template download pages that if people adopt 7.x to use hardware rendering.
Comment 6 Luboš Luňák 2020-07-01 12:06:19 UTC

*** This bug has been marked as a duplicate of bug 134129 ***
Comment 7 Telesto 2020-07-01 12:31:36 UTC
@mwtjunkmail@gmail.com 
Would you mind retesting this.. with a daily build.. not sure if it's resolved

https://dev-builds.libreoffice.org/daily/master/current.html
Comment 8 xordevoreaux 2020-07-01 17:23:49 UTC
(In reply to Telesto from comment #7)
> @mwtjunkmail@gmail.com 
> Would you mind retesting this.. with a daily build.. not sure if it's
> resolved
> 
> https://dev-builds.libreoffice.org/daily/master/current.html

I'll download and take a look.
Comment 9 xordevoreaux 2020-07-01 17:58:00 UTC
Not sure if it's appropriate to call it fixed necessarily, but it's definitely an improvement: https://i.imgur.com/43brkmR.png

Top image is hardware rendering, middle image is Skia without forced software rendering, and bottom is Skia with forced software rendering.

All three had anti-aliasing applied.

Skia with forced software rending is still appreciably blurred, just not nearly to the extent that it was in the first round of testing:
https://i.imgur.com/0NP4IJ8.png

The question now is more of a case of what LO developers consider a close enough approximation for their own level of tolerance. 

It'd be disappointing for this output to be the end-all and be-all of the result, because even with this daily build that I downloaded from your link, Skia visibly remains less than on par with hardware rendering.

Is there necessarily supposed to be a degradation in quality between the three methods (hardware/Skia/Skia forced software rendering) and that's meant to be a known and acceptable trade-off?