xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Mask stuff (and fish slowness)
Date Tue, 24 Oct 2000 14:23:51 GMT

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

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).

View raw message