Issue 122778 - [Fup 122758] Linux display quality of transformed bitmaps needs improvement
Summary: [Fup 122758] Linux display quality of transformed bitmaps needs improvement
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: 4.0.0-dev
Hardware: All Unix, all
: P3 Normal (vote)
Target Milestone: 4.0.1
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords: regression
Depends on: 122796
Blocks:
  Show dependency tree
 
Reported: 2013-07-18 09:20 UTC by Armin Le Grand
Modified: 2017-05-20 10:33 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.1_release_blocker+


Attachments
sample document which clearly shows the problem (18.34 KB, application/vnd.oasis.opendocument.presentation)
2013-07-19 08:58 UTC, hdu@apache.org
no flags Details
Patch with experiments for better and faster sclaing (21.28 KB, patch)
2013-08-14 15:28 UTC, Armin Le Grand
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2013-07-18 09:20:15 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.
Comment 1 Armin Le Grand 2013-07-18 09:20:29 UTC
ALG: Grepping
Comment 2 Armin Le Grand 2013-07-18 15:59:49 UTC
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?
Comment 3 hdu@apache.org 2013-07-19 08:58:20 UTC
Created attachment 81106 [details]
sample document which clearly shows the problem
Comment 4 hdu@apache.org 2013-07-22 14:33:45 UTC
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.
Comment 5 Armin Le Grand 2013-08-14 11:17:22 UTC
ALG: Adding the regression keyword, copied from original task
Comment 6 Armin Le Grand 2013-08-14 15:28:42 UTC
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.
Comment 7 Armin Le Grand 2013-08-14 16:45:48 UTC
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.
Comment 8 Armin Le Grand 2013-08-26 15:19:40 UTC
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...
Comment 9 Armin Le Grand 2013-08-27 12:48:09 UTC
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...
Comment 10 SVN Robot 2013-08-27 12:55:21 UTC
"alg" committed SVN revision 1517803 into trunk:
i122778 Enhanced own transformer for drawing transformed bitmaps which is use...
Comment 11 Armin Le Grand 2013-08-27 13:14:18 UTC
ALG: Checked on Linux, looks good and works well, may be added to AOO401.
Comment 12 Armin Le Grand 2013-08-28 12:53:54 UTC
ALG: Requesting the AOO401 flag...
Comment 13 jsc 2013-08-29 12:25:10 UTC
approve showstopper request
Comment 14 SVN Robot 2013-08-29 12:40:19 UTC
"alg" committed SVN revision 1518625 into branches/AOO401:
i122778 Enhanced own transformer for drawing transformed bitmaps
Comment 15 Armin Le Grand 2013-08-29 12:40:39 UTC
ALG: Checked and added to AOO401
Comment 16 jsc 2013-08-30 09:03:18 UTC
set target milestone
Comment 17 fanyuzhen 2013-08-30 14:06:04 UTC
The latest build in wiki is AOO401m1(Build:9710)  -  Rev. 1516414, wait for revision 1518625 for verification
Comment 18 liuping 2013-09-09 05:35:54 UTC
Verified on AOO401m2(Build:9711)  -  Rev. 1518667
2013-08-20 14:23:59 (Tue, 20 Aug 2013) - MacOS 10.8 ,Pass