Can you attach a sample document, and a screenshot of how it looks like on your system?

Created attachment 83397 [details]
Appearance of image at 200% in Writer OO4.0.1

This is the appearance of an image in Open Office Writer 4.0.1 under Ubuntu 12.04.

Created attachment 83398 [details]
Appearance of image at 200% in Writer OO4.1.0

This is an image whose representation on the screen is degraded upon upgrade to OO4.1.0 under Ubuntu 12.04.

Created attachment 83399 [details]
Document with image whose quality degrades 4.0.1->4.1.0

Confirmed Fedora 20 with the attached document
Regression from 4.0.1
Setting Armin on CC

Adding Herbert to CC. Herbert, any changes on Linux Bitmap drawing between 4.0.1 and 4.1.0...?

From AOO40x->AOO410 Linux bitmap drawing was modified with your changes for bug 122778 ("Linux display quality of transformed bitmaps needs improvement) or eventually bug 124002. These are the most likely candidates for this regression. Simply reverting the changes to test this doesn't work because interfaces change.

Why the problem was not visible on gdiplus and quartz may have to do with the default scaling method in each backend.

Grepping...

Debugging. The paint uses simply fallback to OutputDevice::DrawBitmap() which leads to X11SalGraphics::drawBitmap and X11SalGraphics::ImplDraw. At the involved OutputDevice, mnAntialiasing == 2 which means ANTIALIASING_ENABLE_B2DDRAW.

@Herbert: Shouldn't this paint the bitmap AAed as expected?

I forgot: The same pic in draw/impress shows the same behaviour, thus this is independent of the changes done in Writer for unifying the graphics rendering.

Compared on xubuntu64bit AOO400 and trunk version: When the graphic needs to be compressed (e.g. 70% display zoom), both look bad. When scaled bigger than original (150%) the old version smoothes (somewhat), the trunk version does not, just unequal line/column doubling which looks bad.
Thus there is indeed a difference somewhere. Debugging AOO400 version what was used there...

Loked deeper and indeed the difference is that the old specialized preparation with the GraphicManager paint did the hand-crafted scaling in an own form. The now unified paint is using the default VCL-Based OutputDevice::DrawBitmap which is not AAing on linux at all. The way go get out of this is to enhance the standard VCL bitmap output for Linux.

@Herbert: Is there a simple/overseeable way to get Bitmap/BitmapEx painted with better quality using VCL on Linux? You have a much better overview of the stuff currently done there.

(In reply to Armin Le Grand from comment #12)
> Loked deeper and indeed the difference is that the old specialized
> preparation with the GraphicManager paint did the hand-crafted scaling in an
> own form. The now unified paint is using the default VCL-Based
> OutputDevice::DrawBitmap which is not AAing on linux at all. The way go get
> out of this is to enhance the standard VCL bitmap output for Linux.

With your changes in revision 1403434 the default bitmap scaling has changed form BMP_SCALE_FAST to BMP_SCALE_SUPER ("supersampling"), which IMHO shouldn't be considered an interpolating algorithm. Most other scaling methods result in much nicer looking images. Resampled preview images with an almost matching size also look much nicer, even when only supersampling are used.

In our plain X11 backend the native XCopyArea function is used, which doesn't care at all about antialiasing. And if visual quality is a concern then that function's scaling ability should be avoided. Until your changes for AOO410 (such as issue 122778) this wasn't the case.

I agree that the image scaling functionality on our X11 backend should be improved to better handle image scaling itself, especially when antialiasing is enabled. But for this particular regression I'm afraid we need a solution that gets the old quality back ASAP.

@Herbert: Does this mean that VCL's implementation of X11 bitmap painting cannot/does not scale at all, so that the image that needs to be painted has to be prepared in the target pixel resolution? If yes and if X11 is able to *do* scaling we should consider to use it. Of course we could use own software-based scaling as preprocessing for painting (and thus could control quality), but this is an expensive and not modern solution which I would definitely want to avoid. There *must* be something better nowadays which uses available graphics hardware, even under Linux, don't you think?

Created attachment 84006 [details]
Sample ODT Document with a png on 4.0.1

I can also confirm the issue on Ubuntu 12.04.5 LTS 64 bits.

Linux gpborges 3.13.0-36-generic #63~precise1-Ubuntu SMP Thu Sep 4 22:28:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I'm stuck on 4.0.1 because if I upgrade to 4.1.x (4.1.0, 4.1.1) the images are bad. I'm attaching 2 sample images so that you guys can see it.

Created attachment 84007 [details]
Sample ODT Document with a png on 4.1.0 (same for 4.1.1)

I originally reported this problem in 4.1.0 however it still is present in the 4.2.0 developer build using an updated OS (Ubuntu 15.10).  The absence of antialiasing on the linux build is a usability issue, not just a cosmetic one, as it makes it impossible to work properly with documents with small fonts and images with fine detail.

Reset assigne to the default "issues@openoffice.apache.org".