Bug 86675

Created attachment 109969 [details]
Screenshot 2: LibreOffice 4.3.4 with antialiasing

This is not a blocker. The reduced-quality antialiasing was enabled because of performance reasons AFAIK.

Without antialiasing PNG images are looking very ugly. It would be very nice to reenable good quality antialising or to get the information how to do it.

As bad quality rendering is not state of the art today, I recommend to deal with it as a blocker for releasing LibreOffice 4.4 - expecially compared with LibreOffice 4.3.4.

(In reply to Adolfo Jayme from comment #2)
> This is not a blocker. The reduced-quality antialiasing was enabled because
> of performance reasons AFAIK.

@Adolfo: I'm quite shocked when I paste an image in draw :\
Really looks bad.
We must be sure what is going on here, IMO.

I doublechecked bad performace with image processing with the following results using LibreOffice 4.3.4 and Writer:

(1) Indeed performance of image handling is bad with larger images. It's not possible to scroll without bucking.

(2) Performance issues exist with PNG images as well as with other image formats too, e.g. JPEG.

With the same files (and images) no performance issus exist with AOO 4.1.1. Maybe a look at according AOO code makes sense.

Created attachment 110400 [details]
screen print with image in three versions

For reference a screen print.
From what I understood, developers are working on OpenGL stuff currently, which is where this has to be fixed.

The behaviour changed as of the below commit. Despite the discussion above, the commit message doesn't make it sound like decreased quality was an intended side effect or trade-off.

Adding Cc: to quikee@gmail.com (Tomaž Vajngerl). Could you possibly comment on this one? Thanks


commit 1b23e46051d8cc7c01fd8b4d0ea51bfec145db8e
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Date:   Sat May 31 21:03:34 2014 +0200

    vcl: Refactor scale "super" out of bitmap and make it independent
    
    Introduce BitmapFilter as a general bitmap filtering class, and
    make scale "super" algorithem independent as BitmapScaleSuper
    which uses BitmapFilter as superclass.
    
    This is an ongoing work to make some bitmap algorithms structured
    and more independent from the big bitmap class This will make them
    easier to work with, test and optimize.
    
    Change-Id: I37d29709b2af95cab2f6da21129302f5be79318b

The commit in question just refactors the "super" bitmap scaler out of Bitmap to its own class. It is possible that I made a mistake and produced a bug when refactoring, but I don't see any difference in image scaling between 4.3.4 and 4.4 RC1 or master (tested on Linux). An example document would be helpful.

Created attachment 111556 [details]
Sample document

Created attachment 111557 [details]
Before and after screenshots

(In reply to Tomaz Vajngerl from comment #8)

Please see the attached sample document and screenshots (attachment 111556 [details] and attachment 111557 [details]).

The screenshots are from builds exactly at (right) and one commit before (left) the commit I mentioned above. Current master still looks like the shot on the right to me.

*** Bug 82870 has been marked as a duplicate of this bug. ***

@Matthew: My bug seems different then this as the problem in my bug is between 4.1 and 4.2+ as shown attachment 104986 [details].

Unfortunately the problem shown in sceenshots 1 und 2 still exists using the current master.

Ups.. I commited a fix under fdo#82870 and not this bug as I intended. Still this requires an explanation as it doesn't actually fix this or fdo#82879 bug.

There indeed was a bug in scale super which made "bilinear" scaling into "nearest neighbor" like scaling introduced in [1] but in a later commit [2] we reverted the fix that pre-scaled the images with our built-in scaler - instead of that a fast native "nearest neighbor" scaler is used. So indeed this is the issue Adolfo was talking about which now makes this bug a duplicate of [3]. 

I fixed the issue with super scaler in master by first reverting [2] and looking for the cause of the low quality. 

fdo#82870 is also a duplicate of this and [3] bug.. 

[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b23e46051d8cc7c01fd8b4d0ea51bfec145db8e

[2] http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee36fc7add892690c95a969530ecdcfc1bc9decc

[3] https://bugs.freedesktop.org/show_bug.cgi?id=74124

Tomaž: Let me dump some thoughts here...  The cause is the code at

http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/outdev/bitmap.cxx#n672

This started being used a lot after one of the Armin's/drawinglayer commits.  I tried to work that around by

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3cf3700b7a903e88f5296076c40ae854bce91cdc ,

but that's not the correct fix here, and I'd avoid reverting

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee36fc7add892690c95a969530ecdcfc1bc9decc

Luckily the situation should be better at least on Windows now after

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d87b163f8dc787d3bbb17d4a0008ef60c61fe6b0

and follow-up commits in this area, because now we use the native scaling and alpha rendering much more; but I guess on Linux it is still bad :-(

So if you can make the code around bitmap.cxx:672 using some better scaling algorithm while it still remains fast (enough), that would be awesome :-)  The ultimate solution would be that the drawinglayer would cache the scaled images, and consequently we wouldn't have to do any scaling here at all, but that's a big change...

Hope this helps - thanks so much for looking at this!

*** Bug 82870 has been marked as a duplicate of this bug. ***