You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thierry Kormann <Th...@sophia.inria.fr> on 2000/11/10 20:00:04 UTC

new feature and rendering hints

Hi,

*** new feature proposal ***

I have seen the clip.svg with antialising - really really nice but really 
slower. So, I will try to provide a new feature in the viewer. A simple dialog 
that enables to control the rendering hints. That will also validates that we 
don't hard code rendering hints somewhere in the rendering or filtering 
pipeline.

*** rendering hints ***

Vincent has told me that he will probably add a new rendering hint (for pattern 
if I remember) and thomas has also added a new hint for antialising clip. May 
be it's time to provide a one place for our own new rendering hints. I don't 
know if it's already the case, but it's just a suggestion.

Any comments,
Thierry.

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis






Re: new feature and rendering hints

Posted by Vincent Hardy <vi...@eng.sun.com>.
One optimization would be to use a hard clip if the clip
is a rectangle and the clip in device space is also a rectangle (i.e.,
the transform's getShearX/Y is 0)?
V.

Thomas E Deweese wrote:
> 
> >>>>> "TK" == Thierry Kormann <Th...@sophia.inria.fr> writes:
> 
> TK> *** new feature proposal ***
> 
> TK> I have seen the clip.svg with antialising - really really nice but
> TK> really slower. So, I will try to provide a new feature in the
> TK> viewer. A simple dialog that enables to control the rendering
> TK> hints. That will also validates that we don't hard code rendering
> TK> hints somewhere in the rendering or filtering pipeline.
> 
>     This is a good thing.  We will also want to make use of this when
> doing interactive stuff (dragging etc).
> 
>     Note, the nice got two "really"s the slower only one, so it's a
> net gain :)
> 
> TK> *** rendering hints ***
> 
> TK> Vincent has told me that he will probably add a new rendering hint
> TK> (for pattern if I remember) and thomas has also added a new hint
> TK> for antialising clip. May be it's time to provide a one place for
> TK> our own new rendering hints. I don't know if it's already the
> TK> case, but it's just a suggestion.
> 
>     I didn't add any new hints.  We have had the Anti-Aliasing (AA)
> hint turned on for quite some time.  I just added additional behavior
> that is controlled by this hint.
> 
> ---
> 
>     BTW we have been using clip for things that could be done more
> simply.  For example the top level SVG element has it's clip set to
> the viewBox (ie a rectangle in device coords), this means the whole
> thing gets masked by an AA clip mask, which is 100% opaque _most_ of
> the time.  This didn't affect us as much when we used the g2d's clip
> but now it's much more obvious, in terms of speed (I also noticed it,
> because it exposed a bug with some of the Alpha Premult stuff :().
> 
>     Since these still are clip paths (just simple one's that don't
> benefit from AA) I'm trying to think of a way to minimize the effect,
> other than the obvious but ugly route of adding a new 'bounds'
> property to GraphicsNode or some such similar nonsense.  Some ideas
> are forming but they need more work...
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

new feature and rendering hints

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <Th...@sophia.inria.fr> writes:

TK> *** new feature proposal ***

TK> I have seen the clip.svg with antialising - really really nice but
TK> really slower. So, I will try to provide a new feature in the
TK> viewer. A simple dialog that enables to control the rendering
TK> hints. That will also validates that we don't hard code rendering
TK> hints somewhere in the rendering or filtering pipeline.

    This is a good thing.  We will also want to make use of this when
doing interactive stuff (dragging etc).  

    Note, the nice got two "really"s the slower only one, so it's a
net gain :)

TK> *** rendering hints ***

TK> Vincent has told me that he will probably add a new rendering hint
TK> (for pattern if I remember) and thomas has also added a new hint
TK> for antialising clip. May be it's time to provide a one place for
TK> our own new rendering hints. I don't know if it's already the
TK> case, but it's just a suggestion.

    I didn't add any new hints.  We have had the Anti-Aliasing (AA)
hint turned on for quite some time.  I just added additional behavior
that is controlled by this hint.

---

    BTW we have been using clip for things that could be done more
simply.  For example the top level SVG element has it's clip set to
the viewBox (ie a rectangle in device coords), this means the whole
thing gets masked by an AA clip mask, which is 100% opaque _most_ of
the time.  This didn't affect us as much when we used the g2d's clip
but now it's much more obvious, in terms of speed (I also noticed it,
because it exposed a bug with some of the Alpha Premult stuff :().

    Since these still are clip paths (just simple one's that don't
benefit from AA) I'm trying to think of a way to minimize the effect,
other than the obvious but ugly route of adding a new 'bounds'
property to GraphicsNode or some such similar nonsense.  Some ideas
are forming but they need more work...