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 Thomas E Deweese <th...@kodak.com> on 2000/10/24 16:23:51 UTC
Mask stuff (and fish slowness)
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).
Re: Mask stuff (and fish slowness)
Posted by Vincent Hardy <vi...@eng.sun.com>.
Dean,
Dean Jackson wrote:
>
> > > I can now mask an image by our logo (so the image only shows where
> > > the text is (kind of cool)).
> > >
> >
> > Yup, this is more that kind of cool: it is awsome! I have also played
> > with it and the results are really great (I have attached an example).
>
> Nice example Vincent!
Plane time, plenty of time... :-)
>
> So where's the linearGradient?????
> I had to comment it out for the file to load :(
Sorry about that. I will check-in the code ASAP, but it might take a
while as there have been many changes that I need to sync up with.
>
> I notice you've joined the ligature on the logo - very nice.
This is just so that Thomas and you stop zooming on the defect, ...
just kidding :-)
V.
Re: Mask stuff (and fish slowness)
Posted by Dean Jackson <de...@w3.org>.
> > I can now mask an image by our logo (so the image only shows where
> > the text is (kind of cool)).
> >
>
> Yup, this is more that kind of cool: it is awsome! I have also played
> with it and the results are really great (I have attached an example).
Nice example Vincent!
So where's the linearGradient?????
I had to comment it out for the file to load :(
I notice you've joined the ligature on the logo - very nice.
Dean
Re: Mask stuff (and fish slowness)
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:
VH> What I meant is that it seems there are multiple ways of creating
VH> the mask (e.g., from RGB or ARGB sources), and I was wondering if
VH> we should add something in our test case that would show that this
VH> works.
Well, I believe that right now we _always_ create ARGB. And until
the SourceAlpha stuff is done there isn't any way to get a one band
image.
If it helps I created two test apps for the Red's in question:
sources/org/apache/batik/test/refimpl/filter/Any2LumTst.java
sources/org/apache/batik/test/refimpl/filter/MultiplyAlphaTst.java
It appears they didn't make it into the CVS tree however.
Should I check them in???
Re: Mask stuff (and fish slowness)
Posted by Vincent Hardy <vi...@eng.sun.com>.
Thomas,
Thomas E Deweese wrote:
> > VH> However, I have seen that you have done a lot of work on classes
> VH> and I am not quite sure how to write a test that validates all
> VH> that. May be it would be good to improve my mask.svg to test other
> VH> features?
>
> I'm not 100% certain I understand what you are looking for in the
> testing end. New (or modified) sample files that failed before my
> changes but work after them?
>
> The only piece of additional functionality I added was the masking
> stuff.
What I meant is that it seems there are multiple ways of creating the
mask (e.g., from RGB or ARGB sources), and I was wondering if we should
add something in our test case that would show that this works.
>
> VH> I am on a slow modem line, so I cannot send you a zip with the new
> VH> code. Could someone else send a snapshot to Thomas?
>
> This would be helpful. I have implemented the <image> tag (the
> changes are not very far reaching, other than the obvious ones). I
> don't support SVG right now (mostly since I didn't know how to
> approach it), and the URL (can't be a URI) must be absolute since I
> don't know what my document base is or where to get it from (ideas?).
>
> I can now mask an image by our logo (so the image only shows where
> the text is (kind of cool)).
>
Yup, this is more that kind of cool: it is awsome! I have also played
with it and the results are really great (I have attached an example).
Cheers.
V.
Re: Mask stuff (and fish slowness)
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:
VH> Thierry and I merged the mask code. Everything is in place, with
VH> the following notes:
All sounds good. I'll try and take a look at the Mask and
ConcreteMaskRable stuff. I prefer Mask I only switched the MaskRable
to be consistent :).
VH> However, I have seen that you have done a lot of work on classes
VH> and I am not quite sure how to write a test that validates all
VH> that. May be it would be good to improve my mask.svg to test other
VH> features?
I'm not 100% certain I understand what you are looking for in the
testing end. New (or modified) sample files that failed before my
changes but work after them?
The only piece of additional functionality I added was the masking
stuff.
VH> I am on a slow modem line, so I cannot send you a zip with the new
VH> code. Could someone else send a snapshot to Thomas?
This would be helpful. I have implemented the <image> tag (the
changes are not very far reaching, other than the obvious ones). I
don't support SVG right now (mostly since I didn't know how to
approach it), and the URL (can't be a URI) must be absolute since I
don't know what my document base is or where to get it from (ideas?).
I can now mask an image by our logo (so the image only shows where
the text is (kind of cool)).
Re: Mask stuff (and fish slowness)
Posted by Vincent Hardy <vi...@eng.sun.com>.
Thomas,
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
Filter
(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?
Thanks.
V.
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