Apache OpenOffice (AOO) Bugzilla – Issue 122778
[Fup 122758] Linux display quality of transformed bitmaps needs improvement
Last modified: 2017-05-20 10:33:52 UTC
ALG: Due to the now used DrawTransformedBitmap not being supported on system-level on Linux (X-Servers) a fallback is used who's quality needs improvement. It supports smoothing, but this is not activated.
ALG: Grepping
ALG: This is strange; when I force Win to also use the fallback method, the graphic gets smoothed nicely. What's going wrong on the Linux version?
Created attachment 81106 [details] sample document which clearly shows the problem
The difference seems to be that previously the interpolation-scaled image was rotated whereas now the impSmoothPoint() method uses only up to four neighboring sample pixels to get a target pixel. Especially when the ratio of source to destination sizes is big that sampling method results in pronounced Moiré artifacts.
ALG: Adding the regression keyword, copied from original task
Created attachment 81331 [details] Patch with experiments for better and faster sclaing ALG: Saving unfinished work by adding that patch. It is not finished, a in-between result of forcing the local bitmap transformator to be used on win for debugging.
ALG: Checked the linux version with these changes; faster, better scrolling, but still the bad edges. These do *not* come from the created, self-transformed bitmap, but from painting this scaled when the point limit is reached (there is a maximum square pixels to take into account). When removing this, edges are smooth since the self-prepared transformed bitmap will be the exactly paint size, so no scaling in software in vcl is done anymore. @HDU: Problem emerges in OutputDevice::ImplDrawAlpha; the scaling done there is very rough and produces those bad edges. To switch off size limitation in the creation of self-transformed bitmaps, apply the patch and in BitmapEx::getTransformed let bNeedToReduce never get true.
ALG: Checked that indeed OutputDevice::ImplDrawAlpha also creates another temporary bitmap when source and target scaling is different, so the best solution will be to not use a maximum pixel limit in the case that the target is a window output device; this will need the restrictions of the already added patch so that it cannot get bigger than the actual output area. Trying out...
ALG: Re-started with the applied patch, extended and added better max square pixel bounds for rendering. This is used for all systems where no direct support for transformed graphics is added (Linux currently) and works better now by smoothing better and only preparing visible parts. The patch is bigger than is good for AOO401, but in principle not dangerous. Comitted as r1517803, still thinking about a simple solution for AOO401...
"alg" committed SVN revision 1517803 into trunk: i122778 Enhanced own transformer for drawing transformed bitmaps which is use...
ALG: Checked on Linux, looks good and works well, may be added to AOO401.
ALG: Requesting the AOO401 flag...
approve showstopper request
"alg" committed SVN revision 1518625 into branches/AOO401: i122778 Enhanced own transformer for drawing transformed bitmaps
ALG: Checked and added to AOO401
set target milestone
The latest build in wiki is AOO401m1(Build:9710) - Rev. 1516414, wait for revision 1518625 for verification
Verified on AOO401m2(Build:9711) - Rev. 1518667 2013-08-20 14:23:59 (Tue, 20 Aug 2013) - MacOS 10.8 ,Pass