Issue 106379 - Gradient fill of ellipse extends outside thin border in metafile
Summary: Gradient fill of ellipse extends outside thin border in metafile
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: OOO320m2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-28 13:46 UTC by niklas.nebel
Modified: 2010-01-19 12:18 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Bugdoc (13.46 KB, application/vnd.oasis.opendocument.presentation)
2009-10-28 13:47 UTC, niklas.nebel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description niklas.nebel 2009-10-28 13:46:02 UTC
The bugdoc contains ellipses with a thin border and a gradient fill. When
converted to a metafile, single pixels of the fill can be visible outside of the
border (depending on size and scale).

With a light gradient and dark background these pixels can be somewhat
distracting. It can be a problem with bubble charts, which contain many ellipses
and are rendered into a metafile.
Comment 1 niklas.nebel 2009-10-28 13:47:20 UTC
Created attachment 65700 [details]
Bugdoc
Comment 2 Armin Le Grand 2009-10-29 11:40:38 UTC
AW: It's (again, argh) a problem with Metafiles. It did not get more bad (thus
it's in principle not a regression or a defect), but just is not AntiAliased.
Metafiles are simply not prepared for Antialiased actions.
The actions contained draw the gradient by using (the old and known) XOR
painting trick to avoid the ClipRegion usage. This works, but unfortunately that
XOR actions are contained in the Metafile to actually paint the gradient. Of
course, a XOR action CAN NOT be Antialiased since it's pixel-oriented, thus a
non-AAed visualisation is the result which may stick over the AAed object border.

Someone later tried to add more info by encapsulating all these actions by a
XGRAD_SEQ_BEGIN/XGRAD_SEQ_END and added a MetaGradientExAction which contains a
PolyPolygon and the Gradient information. Some exporters use this to avoid the
problem.

I actually tried to catch the MetaGradientExAction in GDIMetaFile::Play (where
it is too dangerous to do, ust for testing). This works partially. One problem
is that when using the contained info and calling
OutputDevice::DrawGradient(...) the same XOR paint is triggered. This means i
would have to:
- Write another renderer for Metafiles to not have that big change in
GDIMetaFile::Play (the 11th MetaFile interpreter/renderer).
- Rewrite OutputDevice::DrawGradient(...) to work in the AntiAliased case.
A second problem is that the PolyPolygon in MetaGradientExAction does have no
more bezier information; this is removed by purpose by subdivision since
Polygon::GetBoundRect() does not work with beziers and asserts that case. Noone
ever implemented this (!).

All in all: All that fixes in the last time are nothing else than to try to
'fix' that VCL itself is not really prepared for AntiAliased rendering. I more
and more tend to implement the decompose for the MetaFile primitive. When this
is done, a Metafile could be rendered by convering it to primitives completely
and send it over the primitive renderer which completely supports AntiAliasing.
This would have many positive effects seen over a longer time period.

Thinking about all the circumstances...
Comment 3 Armin Le Grand 2009-11-17 14:50:55 UTC
AW: #i106541# solves this problem, too (as expected).
Comment 4 Armin Le Grand 2009-11-23 15:40:44 UTC
AW: Adapted target
Comment 5 Armin Le Grand 2009-11-26 11:34:25 UTC
AW: Checked in installed build, works as expected.
Comment 6 Armin Le Grand 2009-11-26 11:37:43 UTC
AW->WG: Please review.
Comment 7 wolframgarten 2009-11-27 10:44:47 UTC
Verified in CWS.
Comment 8 Armin Le Grand 2010-01-19 12:18:02 UTC
AW: Closing.