DO NOT REPLY - Too many JSVGComponent on a single page cause OutOfMemory exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40
393>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40393





------- Additional Comments From deweeseapache.org  2006-09-05 00:38 -------
(In reply to comment #2)
> Well, i don't have evidence that all the threads lead
to OOM error. But, when
> you have 500 components in a scroll pane, it's not a
good idea to have 500
> threads running in any case... 

   Isn't it a bad idea to have 500 components in the scroll
pane when the
user's going to see, what like 20?  The swing components
are designed to
populate the view on demand. I would suggest using this
feature.

> What's wrong with a dependency on Apache Excalibur
that have 
> thread pool implementation (i'll need to see if it's
good
> for this specific scenario - see bug 40394). 

    I don't have a hard rule against dependencies it's
a matter of balencing the provided functionality vs 
the additional synchronization issues it cause everyone 
(users of Batik now need Batik's version of that library
to match the version that other tools may be using just
as an example).

> You already have js.jar, pdf-transcoder.jar, xerces and

> xml-apis. It's not the first dependency you'd
> introduce.

    The only one above that is a hard dependency is xml-apis
which is kind of required for an XML implementation.
js.jar & pdf-transcoder.jar are only required if you are
using their functionality.  The Xerces dependency is 
configurable (simply requires a SAX 2 interface,
and has recently moved to JAXP).



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

(Switching to batik-dev…)

Thomas DeWeese:
>     The only one above that is a hard dependency is
xml-apis
> which is kind of required for an XML implementation.
> js.jar & pdf-transcoder.jar are only required if
you are
> using their functionality.  The Xerces dependency is 
> configurable (simply requires a SAX 2 interface,
> and has recently moved to JAXP).

I forget: what is Xerces needed for?  Is it just the SAX
parser, because
Java 1.3 didn’t come with one?

I wonder if we shouldn’t provide two distributions, one
which includes
Xerces (and Xalan, for XPath) to work on Java 1.3, and
another that
doesn’t, since Java 1.4 already has them.

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycamjabber.org  â–Ş  ICQ 26955922  â–Ş  MSN cammcc.id.au

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi Cameron,

Cameron McCormack <cammcc.id.au> wrote on
09/04/2006 09:25:54 PM:

> Thomas DeWeese:
> > The Xerces dependency is configurable (simply
requires a SAX 2 
> > interface, and has recently moved to JAXP).
> 
> I forget: what is Xerces needed for?  Is it just the
SAX parser, because
> Java 1.3 didn?t come with one?

   Yes, this is all that it is needed for.

> I wonder if we shouldn?t provide two distributions, one
which includes
> Xerces (and Xalan, for XPath) to work on Java 1.3, and
another that
> doesn?t, since Java 1.4 already has them.

   Well, so this raises an interesting question.  Right now
our
code base will compile with either JDK 1.4 or 1.3 but you
don't
get the same thing when you do this.  Will a JDK 1.4 build
run 
cleanly on JDK 1.3?  I would suspect not since the
JGVTComponent
will try and register a scroll wheel event handler which
doesn't
exist in JDK 1.3.

   This is fine for development/source dist since the build
tools figure this all out for us, but what about when we go
to make a binary distribution?  I think it would be fairly
ugly to
have two binary distributions (one for JDK 1.3, and one for
JDK 1.4+).  Is that commonly done?


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi Cameron,

Cameron McCormack <cammcc.id.au> wrote on
09/04/2006 09:25:54 PM:

> Thomas DeWeese:
> > The Xerces dependency is configurable (simply
requires a SAX 2 
> > interface, and has recently moved to JAXP).
> 
> I forget: what is Xerces needed for?  Is it just the
SAX parser, because
> Java 1.3 didn?t come with one?

   Yes, this is all that it is needed for.

> I wonder if we shouldn?t provide two distributions, one
which includes
> Xerces (and Xalan, for XPath) to work on Java 1.3, and
another that
> doesn?t, since Java 1.4 already has them.

   Well, so this raises an interesting question.  Right now
our
code base will compile with either JDK 1.4 or 1.3 but you
don't
get the same thing when you do this.  Will a JDK 1.4 build
run 
cleanly on JDK 1.3?  I would suspect not since the
JGVTComponent
will try and register a scroll wheel event handler which
doesn't
exist in JDK 1.3.

   This is fine for development/source dist since the build
tools figure this all out for us, but what about when we go
to make a binary distribution?  I think it would be fairly
ugly to
have two binary distributions (one for JDK 1.3, and one for
JDK 1.4+).  Is that commonly done?


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Thomas DeWeese:
>    Well, so this raises an interesting question.  Right
now our
> code base will compile with either JDK 1.4 or 1.3 but
you don't
> get the same thing when you do this.  Will a JDK 1.4
build run 
> cleanly on JDK 1.3?  I would suspect not since the
JGVTComponent
> will try and register a scroll wheel event handler
which doesn't
> exist in JDK 1.3.

You are right, it doesn’t.  I wonder how many users of
Batik actually
need 1.3 support—it must be declining.

>    This is fine for development/source dist since the
build
> tools figure this all out for us, but what about when
we go
> to make a binary distribution?  I think it would be
fairly ugly to
> have two binary distributions (one for JDK 1.3, and one
for
> JDK 1.4+).  Is that commonly done?

That’s a good point.  We haven’t had a release since
that mouse wheel
stuff went in there, have we?  It seems that FOP have 1.3
and 1.4
versions of their release:

http://apache.planetmirror.com/dist/xmlgraphics/fop/

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycamjabber.org  â–Ş  ICQ 26955922  â–Ş  MSN cammcc.id.au

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org