Apache OpenOffice (AOO) Bugzilla – Issue 93485
drawing problems in LinePropertiesDialog when antialiasing is true on Aqua version
Last modified: 2009-01-19 10:04:50 UTC
DEV300_m30 , on Mac OS X 10.4.x , Intel machine Screenshot will be attached To test antialiasing, in Draw, the "Line" dialog box is very usefull, and I think I found an issue with the coming AA. To reproduce : First, you must activate antialiasing (manually) in OpenOffice.org, on Mac OS X: 1. rm -r ~/Library/Application\ Support/OpenOffice*/*/user/registry/cache/ 2. then edit <instdir>/share/registry/schema/org/openoffice/Office/Common.xcs Second, open a new Draw document, and play click on the "Line" icon, left on the toolbar (the second icon starting from left, beside 'Styles and Co' ) Play with the possibilities, and give a != 0 values to some parameters -> as example, see the attached screenshot
Created attachment 56230 [details] a simple screenshot
Fixing a typo in the summary
AW: Another effect i talked about with HDU: When AA under linux, in the line dialog lines are not painted when no transparence is set. Currently this uses a VDEV as buffer device (no direct DrawTransparent for polygon yet), so there must be some error with masking.
AW: started a unxlngi6.pro build. AW: getting unxmacxi.pro environment, starting mac build.
AW: Debugged with HDU on linux version (mac version is ready, too). The basic problem seems to be that the VCLPixelRenderer may fetch the background from it's target device when transparent primitives need to be painted. In the consequence, the SingleObjectPainter (and the ObjectContactOfObjListPainter it is using) do not work with Windows. There are two solutions: (a) Try to get transparent renderings in the VCL renderers work without the need to fetch the background (b) Change all ObjectContactOfObjListPainter users to pre-render in a VDev I know there were some caveats for (a) since i originally started with trying to do (a), but there were cases where this was not possible and leaded to the wrong results. Ironically i cannot exactly remember what was that caveat. Since this would be the better solution, i will try (a) first.
AW: Tried to operate without copying the background and the memory came back: Problem is that without copying the background, not only the content and a alpha mask is needed, but also a mask for the content (which is hard to create). With copying the background, such a mask is not needed since copying unchanged content back to the original with any transparence will lead to the original content. A Second reason is that i use the buffering also for pure masking (no alpha at all) with a given mask using the same effect e.g. with not all areas covering fills (bitmap tile with tiling off). I would also need to rework that. In principle it would always be necessary to do what other systems do: Have a color source, a mask (evtl. 8bit when AA for smooth edges) and a alpha (always 8bit) and combine to target. For mask operations, use source and mask (where mask is a combination of generated from source content and an extra mask painted inverse); for alpha use source, and mask generated from source. In both cases a mask would neeed to be generated from source content what is not cheap. For the current solution i will prefer (b) which allows to not need to generate that mask for content for the cost of copying the source (which is a nice trick, BTW). Caveat is that this will not work directly with windows. I will add an assertion to this and change all users of VCLPixelRenderer to work buffered using local VDevs (e.g. the line preview in the line style dialog).
AW: BTW: I forgot the biggest advantage of (b): The previews will no longer flicker on repaints.
BTW I committed changes in CWS aw058 to the transparent line drawing code which fixes some offsets
AW: Debugged on mac and found (thanks to PL for his assitance). It's in a problem in /vcl/aqua/soure/gdi/salgdi.cxx in AquaSalGraphics::copyBits(...). It does not work when the source and the target have different sizes. Since HDU has no time currently, we changed this to use the fallback formerly commented out with #ifdefs in that case. Created a new task (#i95586#) so that HDU will not forget to fix this place for 3.1. Checked in, done.
AW->WG: Please review as described in the task. Caution! This is for the mac version together with AntiAliasing activated (see task how to do that). Please ask if You have questions.
Verified in CWS.
Tested in m38. Closed.