[Commit] GraphicsUtil...

[Thomas E Deweese <th...@kodak.com>]

I have just committed a fairly large set of changes.

1) Added a new class org.apache.batik.util.awt.image.GraphicsUtil.
   This class centralizes a bunch of code that had been replicated in
   several classes scattered throughout the gvt tree.

   Important methods in GraphicsUtil:
      public static void drawImage(Graphics2D, RenderedImage)
      public static void drawImage(Graphics2D, CachableRed)
      public static void drawImage(Graphics2D, Filter)

      public static void copyData(BufferedImage, BufferedImage)
      public static ColorModel coerceData(WritableRaster wr, ColorModel cm, 
					  boolean newAlphaPreMult)
      public static ColorModel coerceColorModel(ColorModel cm, 
					        boolean newAlphaPreMult)

  The biggest change is the drawImage that takes a filter tries to
  bypass entries in the chain.  This is an important optimization for
  feMerge, which will be very nessisary when we implement
  BackgroundEnable.  It also makes much more of the tree available for
  interactive display.

  The drawImage for Rendered data now requests tiles from tiled sources
  and draws them a tile at a time.  Eventually this should be threaded
  so we are requesting one tile while drawing another but I put this off
  in mind of our threading freeze.

  Note that most of our operations are still untiled, but this is a
  first step in that direction...

2) AbstractGraphicsNode now uses drawImage(Graphics2D, Filter) when
   using 'offscreens'.

3) Lots and lots of minor bug fixes.  The switch to requesting tiles
   as opposed to getData revealed many small bugs.

   a) Do not subclass ConcreteBufferedImageRed to set it's minX minY,
      there is now a constructor that allows you to specify minX, minY.
      Note: In the normal case tileGridOffsetX/Y should equal minX/Y.

   b) Don't subclass BufferedImage to set it's minX, minY (see a).

   c) Don't use y where you mean x :)

   d) Pad was horribly broken and I don't know how we got along with
      it the way it was.  If you want to see somthing kind of neat
      turn on the DEBUG flag in PadRed and bring up FilterRegions. :)

-----

Checking in xml-batik/sources/org/apache/batik/gvt/GraphicsNodeRenderContext.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/bridge/SVGFeGaussianBlurElementBridge.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/bridge/SVGFeImageElementBridge.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/bridge/SVGFeMorphologyElementBridge.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/AbstractGraphicsNode.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/AbstractRed.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/AffineRed.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteBufferedImageCachableRed.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteColorMatrixRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteComponentTransferRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteCompositeRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteDisplacementMapRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteFilterChainRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteGaussianBlurRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteMorphologyRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcretePadRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteRenderedImageCachableRed.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteTileRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteTurbulenceRable.java;
Checking in xml-batik/sources/org/apache/batik/refimpl/gvt/filter/PadRed.java;
Checking in xml-batik/sources/org/apache/batik/util/awt/image/GraphicsUtil.java;

Re: [Commit] GraphicsUtil...

[Vincent Hardy <vi...@eng.sun.com>]

Thomas,

Thomas E Deweese wrote:
> 
> >>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:
> 
> VH> I have a couple questions:
> 
>     [...]
> VH> Well, I noticed yesterday that ConcreteFloodRable is indeed using
> VH> an ugly anonymous subclass on BufferedImage. I will fix to comply
> VH> with your points a and b.
> 
>     I fixed it already (otherwise we would have had significant
> regressions).  As far as I know all the instances of a & b have been
> removed.  There were also ugly anonymous classes used for the filter
> region in the various bridges.  

Yes, this is what I am cleaning up right now and the reason why we
have split the create/build in the GraphicsNode creation and bridging
process.

> These should be removed and replaced
> with a filterRegion Pad thingy, do you agree?
> 
>     I wanted to point it out so you don't do it any more (I noticed
> that TileRable and Displacement also used 'a' so I figured you were
> unaware of the new constructor, or at least still copying bad code :).

Well, I did not know about the new constructor. Sorry.

> 
>     Also while I was working on the changes I noticed that Pad does a
> wierd hybrid device/user space clip.  It properly sets the AOI when it
> calls it's source's createRendering, but when it pads the result it
> does so by transforming the user space padRed to device space and
> padding to that rect.  This is fine for simple scale but if you do
> shear or rotation this is not "correct".
> 

Yes, I have noticed that too and I did not understand why it was
set up this way. I thought you had written that? Did I do that bit?

V.

[Commit] Anonymous subclass fix!

[Thomas E Deweese <th...@kodak.com>]

>>>>> "TD" == Thomas E Deweese <th...@kodak.com> writes:

>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:
VH> I have a couple questions:

TD>     [...]
VH> Well, I noticed yesterday that ConcreteFloodRable is indeed using
VH> an ugly anonymous subclass on BufferedImage. I will fix to comply
VH> with your points a and b.

TD>     I fixed it already (otherwise we would have had significant
TD> regressions).  As far as I know all the instances of a & b have
TD> been removed.  There were also ugly anonymous classes used for the
TD> filter region in the various bridges.  These should be removed and
TD> replaced with a filterRegion Pad thingy, do you agree?

    I was wrong, somehow this fix got 'lost' or I did it in another
class and missed the one in FloodRable.... Anyway here is another
small commit (removed some diagnostics as well...)

    Sorry for the thrashing.

---

Removed diagnostic output from both
Removed subclass nastyness from FloodRable (didn't get committed for some reason).
 
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteCompositeRable.java
CVS:    xml-batik/sources/org/apache/batik/refimpl/gvt/filter/ConcreteFloodRable.java
CVS: ----------------------------------------------------------------------

Re: [Commit] GraphicsUtil...

[Thomas E Deweese <th...@kodak.com>]

>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:

VH> I have a couple questions:

    [...]
VH> Well, I noticed yesterday that ConcreteFloodRable is indeed using
VH> an ugly anonymous subclass on BufferedImage. I will fix to comply
VH> with your points a and b.

    I fixed it already (otherwise we would have had significant
regressions).  As far as I know all the instances of a & b have been
removed.  There were also ugly anonymous classes used for the filter
region in the various bridges.  These should be removed and replaced
with a filterRegion Pad thingy, do you agree?

    I wanted to point it out so you don't do it any more (I noticed
that TileRable and Displacement also used 'a' so I figured you were
unaware of the new constructor, or at least still copying bad code :).


    Also while I was working on the changes I noticed that Pad does a
wierd hybrid device/user space clip.  It properly sets the AOI when it
calls it's source's createRendering, but when it pads the result it
does so by transforming the user space padRed to device space and
padding to that rect.  This is fine for simple scale but if you do
shear or rotation this is not "correct".

    I don't think we are normally hurt by it since our sources
generally pay attention to AOI's that are axially aligned (usually
even if that is in user space).  But it something we should probably
look at...

Re: [Commit] GraphicsUtil...

[Vincent Hardy <vi...@eng.sun.com>]

Thomas,

Cool! I have a couple questions:


> 
>    d) Pad was horribly broken and I don't know how we got along with
>       it the way it was.  If you want to see somthing kind of neat
>       turn on the DEBUG flag in PadRed and bring up FilterRegions. :)

Well, I noticed yesterday that ConcreteFloodRable is indeed using 
an ugly anonymous subclass on BufferedImage. I will fix to comply with
your points a and b.
V.