xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hardy <vincent.ha...@eng.sun.com>
Subject Re: Mask stuff (and fish slowness)
Date Wed, 25 Oct 2000 19:03:06 GMT

Thierry and I merged the mask code. Everything is in place, with 
the following notes:

a. We wrote the bridge differently and similarly to the way filters are
   handled. There is still an unsatisfying bit and Thierry is going to
   discuss the issue with Stephane (this has to do with the way we 
   create GraphicsNode for the mask element content).

b. The Graphics2D/RenderContext synchronization that you had added is
   is in AbstractGraphicsNode (and no longer in extensions such as
   ConcreteShapeNode) because of other changes in the API. However, the
   change has the exact same (very positive) effect.

c. We used the name Mask instead of MaskRable for consistency with
   (and not FilterRable). I hope you wont mind.

I addition, I added modified Mask and ConcreteMaskRable to take into
account the mask region (very similar to filterRegions). 
The samples/tests/mask.svg example illustrates the use. The mask.svg 
example is fairly straightforward and I was mainly trying to validate
the mask regions. However, I have seen that you have done a lot of 
work on classes and I am not quite sure how to write a test that 
validates all that. May be it would be good to improve my mask.svg to 
test other features?

I am on a slow modem line, so I cannot send you a zip with the new
code. Could someone else send a snapshot to Thomas?


Thomas E Deweese wrote:
> Hi all,
>    I have the mask code working thanks to Thierry's suggestion about
> getGraphicsNode.  There are a few outstanding issues (see below)
>    Barring any large objections I would like to check in the stuff I
> have, but since I don't have CVS access up and running I'm looking for
> a sucker^h^h^h^h^h^h volunteer to do the commit.  The diffs (excluding
> new files) from the zipball Dean gave me last week (17th) is ~1000
> lines.
> 1) To get Thierry's suggestion to work I was forced to insert calls to
>    bind in the various GraphicNode create functions.  This seems fine
>    except I suspect that calls need to be added to unbind somewhere
>    when an element goes away or something otherwise we will have a
>    memory leak.
> 2) SVG elements that are in defs aren't instantiated (which is fine).
>    This means that Thierry's suggestion doesn't work for these
>    elements.  Eventually I will need to create the GVT tree for them.
>    The real question is what is the context for the creation.
>    Currently ConcreteGVTBuilder does this for most nodes in the tree,
>    should I replicate it's functionality?  Should the interface for
>    GVTBuilder expand to support these partial trees? (which also
>    requires making it easier to get your hands on the GVT builder).
> 3) I added the code to construct the mask in CSSUtilities
>    (org.apache.batik.refimpl.bridge) as convertMask.  This code makes
>    direct reference to ConcreteMaskRable
>    (org.apache.batik.refimpl.gvt.filter).  Most of the other convert
>    functions go through a factory, but currently one isn't defined in
>    the bridge context.  Since this is a bit similar than most of the
>    other cases that go through a factory, and they both were in
>    refimpl it wasn't immediately clear that the extra complexity was
>    called for.  Thoughts?
> In the process of doing all this I also fixed a number of bugs:
> 1) opacity:0 didn't work, now it does (I use this to hide my mask elems).
> 2) Caching of Stroked paths, the first thing I noticed was how slow
>    batik was running on my system, I tracked it down to the restroking
>    of paths when bounds are computed.  This made a huge difference in
>    my tests (40sec->9sec).  FYI on an ultra 10 the slow document (the
>    fish) paints in .3 sec.
> 3) GraphicsNodeRenderContext, AbstractGraphicsNode was constructing a
>    normal RenderContext for Renderable requests it now uses the
>    GraphicsNodeRenderContext.  Making this work involved making sure
>    everyone kept the graphics2d and the GraphicsNodeRenderContext in
>    sync.  This is fairly annoying to do (and prone to breakage in the
>    future) so we may want to arrange a better system (one idea let the
>    GraphicsNodeRenderContext know about the Graphics2D, so when you
>    update the RenderContext it automatically reflects the change in
>    the Graphics2D, if we get really ambitious we could proxy the
>    Graphics2D so it does something similar).
> 4) Scale extraction now works when there is shear in the matrix.
> 5) Added bind calls in the createGraphicsNode functions...
> 6) ConcreteCanvasGraphicsNode now sets it's composite (no composite
>    means opacity 0).
> 7) fixed a bug in ConcreteBufferedImageCachableRed where it returned
>    a raster with the wrong coordinate system.
> 8) StaticRenderer now adds all the hints from the
>    GraphicsNodeRenderContext to the Graphics2D (this ensures the
>    ability to rebuild a GraphicsNodeRenderContext from a Graphics2D).
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

View raw message