[regression] JSVGCanvas

[Thierry Kormann <Th...@sophia.inria.fr>]

Hi,

Two big troubles with the current JSVGCanvas.

a. On my linux, I have an opaque resize for the windows of my applications. 
When I am resizing the batik frame, it seems that there is as many Threads 
launched as the number of WindowResize events. The result is a really slow 
rendering and a corrupted offscreen image at the end.

b. When selecting an AOI, the AOI rectangle is painted very slowly. I can't do 
a precise selection on the canvas.

Bill, can you fix that as soon as possible, please?

Regards,
Thierry.

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis

Re: [regression] JSVGCanvas

[Bill Haneman <bi...@ireland.sun.com>]

Stephane Hillion wrote:

> Tss, tss.. you changed the behavior: I created a max of one active rendering thread
> per JSVGCanvas/Thumbnail.

I agree that the current behavior is not really OK, especially if you 
rapidly move through "forward" and "back" including a number of
rendering-intensive files.  So I am planning to keep track of the old
thread and interrupt it before starting the new one.  The fix for the
"too-many-paints into global buffer" bug makes the problem more visible,
so if you see a performance regression now, I am working to make
it temporary.

I haven't "re-threaded" the thumbnail code yet, I am waiting until
we agree that the main canvas behavior is OK.

-Bill

--------------
Bill Haneman
+1 353 1 849 0495

Re: [regression] JSVGCanvas

[Bill Haneman <bi...@ireland.sun.com>]

Stephane Hillion wrote:
> 
> Bill Haneman wrote:
> 
> > The old threaded behavior worked the same way, though you may not have noticed
> > how many threads were created because they did not synchronize.
> 
> Tss, tss.. you changed the behavior: I created a max of one active rendering thread
> per JSVGCanvas/Thumbnail.
> As a consequence there was no synchronization problem.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is most definitely not true ;-)

The active rendering threads were using non-synchronized public
variables,
the way the active thread was changed was not thread-safe, and the
rendering
threads themselves sometimes spawned other threads!

> > I do not see any corruption of the buffer when I try this on linux with opaque
> > resizing, by the way.  That part of your report concerns me more.
> 
> What happen is clear: the renderers in each thread render the GVT tree in the
> buffer and then call repaint().

I do not understand what you mean.  In the current implementation each
thread renders into a new buffer which is not yet associated with the
canvas.
 
> > I can limit the number of repaint threads so that no new ones are created until
> > the old one completes, but then issues of whether we interrupt the old one or
> > throw away the new one, making sure the most recent repaint is current, etc. can
> > get messy.
> 
> So messy that you removed the old, working code.
> --
>     Stephane.

If the old code had worked I would not have removed it.  When there is
time I would be happy to show some of the specific things that were
not thread safe.

-Bill

--------------
Bill Haneman
+1 353 1 849 0495

Re: [regression] JSVGCanvas

[Stephane Hillion <St...@sophia.inria.fr>]

Bill Haneman wrote:

> The old threaded behavior worked the same way, though you may not have noticed
> how many threads were created because they did not synchronize.

Tss, tss.. you changed the behavior: I created a max of one active rendering thread
per JSVGCanvas/Thumbnail.
As a consequence there was no synchronization problem.

> I do not see any corruption of the buffer when I try this on linux with opaque
> resizing, by the way.  That part of your report concerns me more.

What happen is clear: the renderers in each thread render the GVT tree in the
buffer and then call repaint().

> I can limit the number of repaint threads so that no new ones are created until
> the old one completes, but then issues of whether we interrupt the old one or
> throw away the new one, making sure the most recent repaint is current, etc. can
> get messy.

So messy that you removed the old, working code.
--
    Stephane.

Re: [regression] JSVGCanvas

[Bill Haneman <bi...@ireland.sun.com>]

Thierry Kormann wrote:
> 
> Hi,
> 
> Two big troubles with the current JSVGCanvas.
> 
> a. On my linux, I have an opaque resize for the windows of my applications.
> When I am resizing the batik frame, it seems that there is as many Threads
> launched as the number of WindowResize events. The result is a really slow
> rendering and a corrupted offscreen image at the end.

I don't think this is actually a regression.  Since the buffer is
invalidated by
resize events (we don't check to see if it's gotten bigger or smaller)
we must re-create the buffer each time we get a resize event.  This is
not
new behavior, though it may have temporarily looked better during the
time
threaded offscreen buffer repaints were turned off (yesterday).  The
old threaded behavior worked the same way, though you may not have
noticed
how many threads were created because they did not synchronize.  
I do not see any corruption of the buffer when I try this on linux with 
opaque resizing, by the way.  That part of your report concerns me more.

I can limit the number of repaint threads so that no new ones are
created
until the old one completes, but then issues of whether we interrupt the
old one or throw away the new one, making sure the most recent repaint
is
current, etc. can get messy.    

> b. When selecting an AOI, the AOI rectangle is painted very slowly. I can't do
> a precise selection on the canvas.

I'll have a look at this one.

> Bill, can you fix that as soon as possible, please?

I am working full-time on JSVGCanvas.  The thread issues are horrendous,
so please don't expect an instant fix.  

The "right" thing to do is rewrite JSVGCanvas and also, possibly, parts
of
GVT and Renderer :-(  However I remain hopeful that we can patch
what we have into reasonable stability.  If we disable threading
altogether,
in line with my first commits yesterday, the subjective "coolness" of
the
viewer is impacted an awful lot.

-Bill

> Regards,
> 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

-- 
--------------
Bill Haneman
+1 353 1 849 0495

slow zoom selection [was Re: [regression] JSVGCanvas]

[Bill Haneman <bi...@ireland.sun.com>]

Thierry Kormann wrote:


> b. When selecting an AOI, the AOI rectangle is painted very slowly. I can't do
> a precise selection on the canvas.
> 
> Bill, can you fix that as soon as possible, please?

The rectangle that is selected during a mouse drag is indeed drawn 
slowly on linux.  However I have re-checked this code and there have 
been no changes to the code called by the mouse listener, nor by
any routines indirectly called.  I have confirmed that only about
4 mouse dragged events per second are being caught.  There is only 
one running thread :-)

So perhaps something else has happened to slow down
the calls to JCanvas.paintImmediately ?  I remember the AOI selection as
always being slow on linux.

-Bill

--------------
Bill Haneman
+1 353 1 849 0495