UpdateManager.repaint() and fireGraphicsNodeChange...

[Lukasz Matuszczak <l....@atrem.pl>]

In my fight with SwingGraphicsNode I'm trying to repaint it (inside JSVGCanvas) 
after intercepting repaint method call on a swing component. I'm calling 
fireGraphicsNodeChangeStarted() and fireGraphicsNodeChangeCompleted() in 
overridden repaint() method but I don't see any results until there is some 
mouse event sent to JSVGCanvas.
I've found out that UpdateManager must be somehow notified about new changes, 
but I can't call UpdateManager.repaint() directly because it's protected.

Thus my current solution is:
    public void repaint(long tm, int x, int y, int width, int height) {
        fireGraphicsNodeChangeStarted();
        fireGraphicsNodeChangeCompleted();
        ctx.getUpdateManager().getUpdateRunnableQueue().invokeLater(
            new Runnable() {

              public void run() {
              }
            });
      }
    }

It looks terrible, but it almost works (sometimes the component seems to be not 
repainted, or repainted too late). I would like to know if there is another 
proper way to force node to be repainted.

Regards,
Lukasz Matuszczak





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

Re: UpdateManager.repaint() and fireGraphicsNodeChange...

[Thomas DeWeese <Th...@Kodak.com>]

Hi Lukasz,

Lukasz Matuszczak wrote:
> In my fight with SwingGraphicsNode I'm trying to repaint it (inside 
> JSVGCanvas) after intercepting repaint method call on a swing component. 
> I'm calling fireGraphicsNodeChangeStarted() and 
> fireGraphicsNodeChangeCompleted() in overridden repaint() method but I 
> don't see any results until there is some mouse event sent to JSVGCanvas.
> I've found out that UpdateManager must be somehow notified about new 
> changes, but I can't call UpdateManager.repaint() directly because it's 
> protected.
> 
> Thus my current solution is:

    Well you shouldn't be calling the
fireGraphicsNodeChangeStarted/Completed methods outside of the
UpdateManager thread (or else you risk concurrent modification
exceptions). So I would suggest that the correct thing is:

public void repaint(long tm, int x, int y, int width, int height) {
        ctx.getUpdateManager().getUpdateRunnableQueue().invokeLater(
            new Runnable() {
              public void run() {
        		fireGraphicsNodeChangeStarted();
        		fireGraphicsNodeChangeCompleted();
              }
            });
      }
    }

> It looks terrible, but it almost works (sometimes the component seems to 
> be not repainted, or repainted too late). I would like to know if there 
> is another proper way to force node to be repainted.

    No the UpdateManager (as it's name would suggest) is the manager of
all updates/repaints.  Since the updates/repaints can not occur while
the DOM/GVT are being modified the the only proper way to trigger
a repaint is to have control of the update thread.  I wouldn't be
surprised if your issues with repaints are related to not calling
changeStarted/completed from the Update Manager thread.  You should
be aware that like with swing if someone/something is 'tying up'
the UpdateManager thread your updates will be delayed until they are
done.

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