xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Slow svg rendering on MAC (again)
Date Tue, 13 Mar 2007 23:02:42 GMT
Hi Martin,
    This is useful information.

Martin Constantine <mackaw@lecture123.com> wrote on 03/13/2007 09:04:12 
AM:

> I found the true root cause of the slow down. [...] One in particular 
> was setting the "shape-rendering" property to "geometricprecision". 
> When this property is left alone (shows as "auto" in the dom viewer) 
> all is well with the world.

> I hope this helps anyone who is or gets stuck in the future. Speaking of 

> which, is this fixable in batik?

    Well all that setting shape-rendering to geometricPrecision does is
set the Java2D rendering hints:

            hints.put(RenderingHints.KEY_RENDERING,
                      RenderingHints.VALUE_RENDER_QUALITY);
            hints.put(RenderingHints.KEY_ANTIALIASING,
                      RenderingHints.VALUE_ANTIALIAS_ON);
            hints.put(RenderingHints.KEY_STROKE_CONTROL,
                      RenderingHints.VALUE_STROKE_PURE);

     I suspect that it's just one of these that is causing
the problem but in any case the only "fix" would be to
avoid setting (one or more) of these hints on the Mac.

> Martin Constantine wrote:
> 
> > hi Thomas, all,
> >
> > I've tracked down the bottleneck in the rendering from our app. From 
> > what I see it is indeed happening in batik somewhere. After some 
> > careful digging, I found that the delay on the mac happens in 
> > GVTTreeRenderer ( I timed between gvtRenderingStarted() and 
> > gvtRenderingCompleted() ). I also verified that at the beginning and 
> > at the end of rendering, the image renderer in GVTTreeRenderer is 
> > indeed a MacRenderer.
> >
> > I also ran squiggle on the same code base and found the following:
> >
> > 1) Surprisingly, svg files with large images and svg fonts based on 
> > system-recognized fonts rendered almost instantaniously.
> >
> > 2) Files with svg fonts (created from non-system fonts elsewhere) took 

> > some time to load.
> >
> > So....
> >
> > Why does the same svg document load in Squiggle much faster (same as 
> > windows) than in our app? The app uses JSVGComponent's 
> > setSVGDocument() method to initiate the tree building. Does squiggle 
> > do something differently? One thought that came to mind was that 
> > perhaps its a memory issue. The app is currently fed 100M to start and 

> > to live with. Does anyone know if perhaps the JVM is not being 
> > allocated this on the mac? (This has worked well on windows). Any 
> > hints would be greatly appreciated. Thanks in advance.
> >
> > Martin.
> >
> >
> >
> > thomas.deweese@kodak.com wrote:
> >
> >> Hi Martin,
> >>
> >> Martin Constantine <mackaw@lecture123.com> wrote on 03/06/2007 
> >> 04:43:56 AM:
> >>
> >> 
> >>
> >>> Just in case this slipped under the radar...Any word on this? Please 

> >>> let 
> >>
> >>
> >> 
> >>
> >>> me know if there's anything I can do to help. Thanks.
> >>> 
> >>
> >>
> >>   I don't have a suitable machine to test on, but my guess would be 
it's
> >> either the clip-path or the SVG font/text.  The clip-path (at least 
> >> in this case)
> >> is useless so you could skip it.   You should be able to strip
> >> out elements and see which causes the problem.
> >>
> >> 
> >>
> >>> Martin Constantine wrote:
> >>> 
> >>>
> >>>> Thomas,
> >>>>
> >>>> I've attached two documents:
> >>>> 
> >>>
> >>> ...
> >>>
> >>> 
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: 
batik-users-unsubscribe@xmlgraphics.apache.org
> >>> For additional commands, e-mail: 
> >>> batik-users-help@xmlgraphics.apache.org
> >>>
> >>> 
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 
batik-users-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: 
batik-users-help@xmlgraphics.apache.org
> >> 
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: 
batik-users-help@xmlgraphics.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message