You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Archie Cobbs <ar...@awarix.com> on 2005/02/16 18:19:10 UTC
Batik drawing in the wrong thread?
We got a core dump from the JDK running Batik. The same problem was
previously reported on this list:
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg05946.html
Although this is obviously a JVM bug and not a Batik bug, the last
comment to this posting..
http://forum.java.sun.com/thread.jspa?threadID=560000&messageID=2752247
seems to imply that the bug is being *triggered* by Batik's incorrectly
invoking AWT methods not from within the Swing thread. Indeed, from the
stack trace it appears Batik is invoking sun.java2d.SunGraphics2D.draw()
from a different thread than the AWT thread.
Is this analysis correct? Or is the stack trace legitimate?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
Re: Batik drawing in the wrong thread?
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
>> A little bit off topic, does the shape-rendering and text-rendering is
>> inherited (by default) by child element or I must specify those
>> attributes on each element ?
>
>
> They are CSS properties, so they are inherited down a subtree
> unless something (style rule or what ever) changes it.
BTW, if you care about the accuracy of the rendering image, I
recommend using "geometricPrecision". We have a drawing application
and this made a big difference in quality, at some expense in speed.
For performance, we draw using Java2D, and then at "mouse up" we
convert these to SVG. Prior to specifying the shape-rendering
property, the SVG rendition of the objects did not match the Java2D
rendering, and so you would see "movement" as the canvas rendered all
of the lines. With geometricPrecision there is less dancing around,
and the resulting image is more faithful.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Tonny Kohar wrote:
>> BTW it's shape-rendering="optimizeSpeed" (text-rendering uses
>>'crispEdges').
BTW I finally broke down and looked it up, it's either for
shape-rendering.
> A little bit off topic, does the shape-rendering and text-rendering is
> inherited (by default) by child element or I must specify those
> attributes on each element ?
They are CSS properties, so they are inherited down a subtree
unless something (style rule or what ever) changes it.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> BTW it's shape-rendering="optimizeSpeed" (text-rendering uses
> 'crispEdges').
A little bit off topic, does the shape-rendering and text-rendering is
inherited (by default) by child element or I must specify those
attributes on each element ?
Thanks
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Archie Cobbs wrote:
> Thanks for the help & insights. I'll post to the list if I learn
> anything more.
BTW it's shape-rendering="optimizeSpeed" (text-rendering uses
'crispEdges').
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
>> Further research.. could it be related to this bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4587651
>
> Hmm, I don't think so, note that the first problem (yours)
> has to do with when the system is 'dropping' a renderer (which
> syncs in my mind with the GC issue).
>
> Bug 4587651 seems to happen when setting up the renderer,
> and seems focused on input data to the rendering.
>
>> and if so, is turning of anti-aliasing the right workaround?
>> (what is the correct way to do that?)
>
> The simplest way to do that is to set shape-rendering="crispEdges"
> on the outermost SVG element. I guess it may be worth a try for you
> (even if the two aren't related this may fix it as it will make it
> use a totally different, probably much simpler, rendering path which
> may avoid the GC issue as well).
Thanks for the help & insights. I'll post to the list if I learn
anything more.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Archie,
Archie Cobbs wrote:
> Further research.. could it be related to this bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4587651
Hmm, I don't think so, note that the first problem (yours)
has to do with when the system is 'dropping' a renderer (which
syncs in my mind with the GC issue).
Bug 4587651 seems to happen when setting up the renderer,
and seems focused on input data to the rendering.
> and if so, is turning of anti-aliasing the right workaround?
> (what is the correct way to do that?)
The simplest way to do that is to set shape-rendering="crispEdges"
on the outermost SVG element. I guess it may be worth a try for you
(even if the two aren't related this may fix it as it will make it
use a totally different, probably much simpler, rendering path which
may avoid the GC issue as well).
> See also bug #6174796.
> Bug #4587651 has a nice 100% reproducible test case.
>
> If this is indeed the problem, perhaps a FAQ entry would be in order.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
>> We got a core dump from the JDK running Batik. The same problem was
>> previously reported on this list:
>>
>> http://koala.ilog.fr/batik/mlists/batik-users/archives/msg05946.html
>
> The stack trace looks fine, but I've always understood that
> rendering to an offscreen buffer was fine as long as the drawing
> is done in one thread.
Further research.. could it be related to this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4587651
and if so, is turning of anti-aliasing the right workaround?
(what is the correct way to do that?) See also bug #6174796.
Bug #4587651 has a nice 100% reproducible test case.
If this is indeed the problem, perhaps a FAQ entry would be in order.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Batik drawing in the wrong thread?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Archie,
Archie Cobbs wrote:
> We got a core dump from the JDK running Batik. The same problem was
> previously reported on this list:
>
> http://koala.ilog.fr/batik/mlists/batik-users/archives/msg05946.html
>
> Although this is obviously a JVM bug and not a Batik bug, the last
> comment to this posting..
>
> http://forum.java.sun.com/thread.jspa?threadID=560000&messageID=2752247
I don't know Ernimril is but from everything I know he is wrong
in this case. It is true that Swing is off limits out of the AWT
thread and drawing to Component.getGraphics (or caching the Graphics
passed to paint) would be problematic.
However my understanding is that, Java2D _should_ work fine in any
single thread - all our drawing is restricted to either the Update
thread or the GVT render thread (never both).
> seems to imply that the bug is being *triggered* by Batik's incorrectly
> invoking AWT methods not from within the Swing thread. Indeed, from the
> stack trace it appears Batik is invoking sun.java2d.SunGraphics2D.draw()
> from a different thread than the AWT thread.
>
> Is this analysis correct? Or is the stack trace legitimate?
The stack trace looks fine, but I've always understood that
rendering to an offscreen buffer was fine as long as the drawing
is done in one thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org