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 Thierry Kormann <Th...@sophia.inria.fr> on 2000/11/09 18:18:28 UTC
Re: BridgeEventSupport.java
> I feel that no further threading work should be done in
> Batik until we have done some "design" in this area. (I'd like to
> make an exception however, and go ahead and commit thread fixes in the
> document loader which I have been working on for a couple of days -
> the existing thread code introduced in the viewer awhile ago is unsafe
> in its current form. :) If anyone would like to review the code first
> please say so now and I will forward it on...
That's fine for me if we have no regression :)
I think you might try some huge documents (ausmap.svg and others...)
If you need some, let me know.
> Without some coordination in this area, it's easy to get things wrong
> in ways that cause weird and difficult to diagnose problems in areas
> that appear to be remote from the code changes themselves.
I agree.
> My vote would be to remove the threading from the script engines
> now, and discuss solutions after 0.1 when everyone has had a chance to
> look carefully at the code and think carefully about the issues.
I agree. My vote is : Let's wait 0.1
Thierry.
--
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis
Re: BridgeEventSupport.java
Posted by Vincent Hardy <vi...@eng.sun.com>.
Good point: what about calling it Batik 2.5 ;-), just kidding!
If everyone agrees, let's call the first release Batik 1.0 [Beta?].
Opinions?
V.
Stephane Hillion wrote:
>
> Vincent Hardy wrote:
>
> > I also agree with Bill and Thierry. Let's make the changes on document
> > loading, then no more threading work until we do real design work for 0.1.
>
> Of course I agree too, except for one thing: I hope the version number of the
> first release of Batik will not be 0.1...
> Just because I do not even download a software with version < 1.0 :)
> --
> Stephane.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: BridgeEventSupport.java
Posted by Stephane Hillion <St...@sophia.inria.fr>.
Vincent Hardy wrote:
> I also agree with Bill and Thierry. Let's make the changes on document
> loading, then no more threading work until we do real design work for 0.1.
Of course I agree too, except for one thing: I hope the version number of the
first release of Batik will not be 0.1...
Just because I do not even download a software with version < 1.0 :)
--
Stephane.
Re: BridgeEventSupport.java
Posted by Vincent Hardy <vi...@eng.sun.com>.
I also agree with Bill and Thierry. Let's make the changes on document
loading, then no more threading work until we do real design work for
0.1.
V.
Thierry Kormann wrote:
>
> > I feel that no further threading work should be done in
> > Batik until we have done some "design" in this area. (I'd like to
> > make an exception however, and go ahead and commit thread fixes in the
> > document loader which I have been working on for a couple of days -
> > the existing thread code introduced in the viewer awhile ago is unsafe
> > in its current form. :) If anyone would like to review the code first
> > please say so now and I will forward it on...
>
> That's fine for me if we have no regression :)
> I think you might try some huge documents (ausmap.svg and others...)
> If you need some, let me know.
>
> > Without some coordination in this area, it's easy to get things wrong
> > in ways that cause weird and difficult to diagnose problems in areas
> > that appear to be remote from the code changes themselves.
>
> I agree.
>
> > My vote would be to remove the threading from the script engines
> > now, and discuss solutions after 0.1 when everyone has had a chance to
> > look carefully at the code and think carefully about the issues.
>
> I agree. My vote is : Let's wait 0.1
>
> Thierry.
>
> --
> Thierry Kormann
> email: Thierry.Kormann@sophia.inria.fr http://www.inria.fr/koala/tkormann/
> Koala/Dyade/Bull @ INRIA - Sophia Antipolis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [commit] Viewer thread changes
Posted by Stephane Hillion <St...@sophia.inria.fr>.
Bill Haneman wrote:
> (*)However forward and back do not seem to be working at the moment,
> I don't remember when they stopped working so perhaps this
> is not my regression? I will investigate tomorrow.
As I coded this stuff, it took me one minute to find and fix the problem.
And you will have more time tomorrow to do much more interesting things ;)
--
Stephane.
[commit] Viewer thread changes
Posted by Bill Haneman <bi...@ireland.sun.com>.
Hi:
I have recently completed a commit which makes changes to
batik.apps.svgviewer.ViewerFrame. ViewerFrame now creates
background document loading threads via new class
batik.util.DocumentLoadRunnable's createLoaderThread(...)
method. This background thread communicates with its
creator via instances of new class batik.util.DocumentEvent
(DocumentLoadingEvent, DocumentPropertyEvent). There is
an associated batik.util.DocumentListener interface.
I have seen no regressions (*) other that some sluggishness
in actually executing "stop" when loading a file. This is,
I think, a necessary evil since the snappy behavior
before was a product of background threads calling
methods in Swing components, and calls to thread.stop(),
both of which are unsafe. Note that at least with local files,
most of the time seems to be spent rendering, and at the moment
there is no clean way of interrupting a repaint. The old
code did it by killing the non-AWT thread that was doing the
repainting - fast but very dangerous. Since we now rely on
invokeLater(), our requests (updating UI components,
message bars, etc.) must wait until the AWT event thread
(including all redraws) is at least momentarily idle.
However, stop works well for remote files and other
situations where loading or parsing are time-consuming.
Finding a way to interrupt repaint, which may be important
for animation and scripting, will take a but more thought. :-)
One important aspect of this "commit" is that the dispatching of
DocumentEvents by DocumentLoadRunnable is accomplished by
wrapping the event state in a Runnable which is scheduled for
execution in the AWTEvent thread via
javax.swing.SwingUtilities.invokeLater(Runnable r).
(Recall that since java event dispatches are usually just
method calls, so the event handlers are otherwise executed in
the thread which creates and dispatches the events.) This
means that it is safe for the event handlers to do things that
will change JComponent contents, mark them dirty, force
repaints, etc.
To help enforce this I will shortly checking a minor change
that introduces interface DocumentEventSource, requiring
a method called dispatchAsyncDocumentEvent().
There may be scope in the future for merging the new class
DocumentLoadRunnable with the existing batik.dom.DocumentLoader
classes, etc. I expect that the asynchronous loading of
documents, with a safe notification mechanism, is something that
we will have broad use for.
There are a number of modifications that could be put in place -
our events could contain their own async dispatch methods,
relieving the event sources from having to think about this...
for instance DocumentEvent.dispatchAsync(List docListeners)
could replace dispatchAsyncDocumentEvent(DocumentEvent e).
But the end result would be very nearly the same.
In order to allow document loading, DOM building, and other
I/O to be interrupted gracefully, I now trap InterruptedIOEvent
in some classes that do Reader or InputStream I/O, and
rethrow an InterruptedException. So a number of document loading
classes now throw this exception, which should be caught.
Lastly, I also commented out traces in StrokingTextPainter...
if I need traces again I will build a utility class along
the lines of my earlier suggestion, with Vincent's suggested
modifications - unless someone else builds it first!
-Bill
P.S. - I have confirmed that a fresh checkout+compile+run
works for the sample files.
(*)However forward and back do not seem to be working at the moment,
I don't remember when they stopped working so perhaps this
is not my regression? I will investigate tomorrow.
----------------
Bill Haneman
+1 353 1 849 0495
Re: [commit] Thread stuff
Posted by Stephane Hillion <St...@sophia.inria.fr>.
Bill Haneman wrote:
> Also note that in some cases we want to block until our event has
> been "delivered" (i.e. run), in which case we can use
> invokeAndWait().
Such a case is in DocumentLoadRunnable.run():
fireDocumentEvent(
new DocumentLoadingEvent(
DocumentLoadingEvent.LOADED, doc));
...
float w = elt.getWidth().getBaseVal().getValue();
This code produces sometimes a NullPointerException due to a race
condition:
CSSLength.getValue() needs a fully initialized SVGContext, what is
done by the DocumentLoadRunnable listener.
--
Stephane.
Re:[commit] Thread stuff
Posted by Bill Haneman <bi...@ireland.sun.com>.
Bill Haneman wrote:
I have noticed a few minor things that I should clean up as I
investigate
the Forward/Back actions.
Also, we probably should replace
javax.swing.SwingUtilities.invokeLater()
with
java.awt.EventQueue.invokeLater()
(though they are really the same thing).
Also note that in some cases we want to block until our event has
been "delivered" (i.e. run), in which case we can use
invokeAndWait().
-Bill
--------------
Bill Haneman
+1 353 1 849 0495
Re: BridgeEventSupport.java
Posted by Bill Haneman <bi...@ireland.sun.com>.
Christophe Jolif wrote:
> So if nobody have strong objections for removal threading in script
> until tomorrow, I will remove it as it seems some problems may appear if
> we don't think carefully about it before implementing it.
OK, but please wait a few minutes!
I have been trying to do a merge/commit for hours.. :-)
anybody notice that the
update/merge/update/clean/compile/runtime-error/update/clean/compile/commit-fail/update/merge
cycle is getting longer ?
-Bill
--------------
Bill Haneman
+1 353 1 849 0495
Re: BridgeEventSupport.java
Posted by Christophe Jolif <cj...@ilog.fr>.
Thierry Kormann wrote:
>
> > I feel that no further threading work should be done in
> > Batik until we have done some "design" in this area. (I'd like to
> > make an exception however, and go ahead and commit thread fixes in the
> > document loader which I have been working on for a couple of days -
> > the existing thread code introduced in the viewer awhile ago is unsafe
> > in its current form. :) If anyone would like to review the code first
> > please say so now and I will forward it on...
>
> That's fine for me if we have no regression :)
> I think you might try some huge documents (ausmap.svg and others...)
> If you need some, let me know.
>
> > Without some coordination in this area, it's easy to get things wrong
> > in ways that cause weird and difficult to diagnose problems in areas
> > that appear to be remote from the code changes themselves.
>
> I agree.
>
> > My vote would be to remove the threading from the script engines
> > now, and discuss solutions after 0.1 when everyone has had a chance to
> > look carefully at the code and think carefully about the issues.
>
> I agree. My vote is : Let's wait 0.1
So if nobody have strong objections for removal threading in script
until tomorrow, I will remove it as it seems some problems may appear if
we don't think carefully about it before implementing it.
--
Christophe