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 Marco Herrn <ml...@mherrn.de> on 2012/11/02 14:53:02 UTC

Re: When is the UpdateManager definitely available?

Hi,

I must push this mail again.
It now happened again multiple times to me, that the the method
canvas.getUpdataManager() returned null when the gvgTreeRenderer completed.
It happens seldom, but it does happen.

Please see again the code snipped in the quoted text.

Is it a bug in batik? According to the javadoc of the getUpdateManager()
method I would expect that it is guaranteed that getUpdateManager() won't
return null when being called after being informed of rendering completion.

Any help appreciated.
Regards
Marco


On Fri, Jul 20, 2012 at 03:38:45PM +0200, ml@mherrn.de wrote:
> Hi I am using the following code:
> 
> canvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
>         @Override
>         public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
>           canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>         }
>       });
> 
> to do some changes in the DOM of an SVG document. I expected that the
> updatemanager is definitely available when gvtRenderingCompleted was
> called.
> However, it now happened at least once that I got a NullPointerException
> on the line
>   canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
> 
> So it seems that there is still no guarantee that the UpdateManager is
> available then. Am I missing something? Must I register on a different
> listener?

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


Re: When is the UpdateManager definitely available?

Posted by Marco Herrn <ml...@mherrn.de>.
Hi Jonathan,

thanks for your answer.
The gvgBuildCompleted is fired even earlier than gvtTreeRenderingCompleted.
So it may be a good option to use, but shouldn't help me with my exact
problem.
Maybe the answer from Thomas points to the right direction.


On Fri, Nov 02, 2012 at 04:53:37PM -0400, jonathan wood wrote:
>    Hi Marco,�
>    � I use a slightly different overload:
>    � � � � canvas.addGVTTreeBuilderListener(new GVTTreeBuilderAdapter() {
>    � � � � � � @Override
>    � � � � � � public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
>    � � � � � � � � // do stuff � � � � � � � �
>    � � � � � � }
>    � � � � });
>    On Fri, Nov 2, 2012 at 9:53 AM, Marco Herrn <[1...@mherrn.de> wrote:
> 
>      Hi,
> 
>      I must push this mail again.
>      It now happened again multiple times to me, that the the method
>      canvas.getUpdataManager() returned null when the gvgTreeRenderer
>      completed.
>      It happens seldom, but it does happen.
> 
>      Please see again the code snipped in the quoted text.
> 
>      Is it a bug in batik? According to the javadoc of the getUpdateManager()
>      method I would expect that it is guaranteed that getUpdateManager()
>      won't
>      return null when being called after being informed of rendering
>      completion.
> 
>      Any help appreciated.
>      Regards
>      Marco
> 
>      On Fri, Jul 20, 2012 at 03:38:45PM +0200, [2]ml@mherrn.de wrote:
>      > Hi I am using the following code:
>      >
>      > canvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
>      > � � � � @Override
>      > � � � � public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
>      > � � � � �
>      canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>      > � � � � }
>      > � � � });
>      >
>      > to do some changes in the DOM of an SVG document. I expected that the
>      > updatemanager is definitely available when gvtRenderingCompleted was
>      > called.
>      > However, it now happened at least once that I got a
>      NullPointerException
>      > on the line
>      > �
>      canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>      >
>      > So it seems that there is still no guarantee that the UpdateManager is
>      > available then. Am I missing something? Must I register on a different
>      > listener?
> 
>      ---------------------------------------------------------------------
>      To unsubscribe, e-mail:
>      [3]batik-users-unsubscribe@xmlgraphics.apache.org
>      For additional commands, e-mail:
>      [4]batik-users-help@xmlgraphics.apache.org
> 
> References
> 
>    Visible links
>    1. mailto:ml@mherrn.de
>    2. mailto:ml@mherrn.de
>    3. mailto:batik-users-unsubscribe@xmlgraphics.apache.org
>    4. mailto:batik-users-help@xmlgraphics.apache.org

-- 
Marco Herrn - IT-Berater Individualsoftware
(GnuPG/PGP encrypted mail preferred)
Key ID: 94620736

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


Re: When is the UpdateManager definitely available?

Posted by jonathan wood <jo...@gmail.com>.
Hi Marco,

  I use a slightly different overload:

        canvas.addGVTTreeBuilderListener(new GVTTreeBuilderAdapter() {
            @Override
            public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
                // do stuff
            }
        });


On Fri, Nov 2, 2012 at 9:53 AM, Marco Herrn <ml...@mherrn.de> wrote:

> Hi,
>
> I must push this mail again.
> It now happened again multiple times to me, that the the method
> canvas.getUpdataManager() returned null when the gvgTreeRenderer completed.
> It happens seldom, but it does happen.
>
> Please see again the code snipped in the quoted text.
>
> Is it a bug in batik? According to the javadoc of the getUpdateManager()
> method I would expect that it is guaranteed that getUpdateManager() won't
> return null when being called after being informed of rendering completion.
>
> Any help appreciated.
> Regards
> Marco
>
>
> On Fri, Jul 20, 2012 at 03:38:45PM +0200, ml@mherrn.de wrote:
> > Hi I am using the following code:
> >
> > canvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
> >         @Override
> >         public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
> >
> canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
> >         }
> >       });
> >
> > to do some changes in the DOM of an SVG document. I expected that the
> > updatemanager is definitely available when gvtRenderingCompleted was
> > called.
> > However, it now happened at least once that I got a NullPointerException
> > on the line
> >
> canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
> >
> > So it seems that there is still no guarantee that the UpdateManager is
> > available then. Am I missing something? Must I register on a different
> > listener?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>

Re: When is the UpdateManager definitely available?

Posted by Marco Herrn <ml...@mherrn.de>.
Hi Thomas,

On Fri, Nov 02, 2012 at 07:52:38PM -0400, DeWeese Thomas wrote:
>    I think your current method should work (unless of course the document isn't dynamic in which case it may never have an UpdateManager).

Yes, my document is dynamic.

>  You might also consider listening to the onload event (either on the document using DOM events, or you can register an SVGLoadEventDispatcherListener with the canvas directly.

The javadoc of the getUpdateManager() method talks about registering a
GVTTreeRendererListener. When is it advised to use the
GVTTreeRendererListener and when the SVGLoadEventDispatcherListener (or the
GVTTreeBuilderListener as Jonathan said)?

>    However without knowing your application at all I wonder if possibly the problem isn't listening to early but listening too late, i.e. you request the UpdateManager after it has been discarded (which might happen if you dispose of the document shortly after it has finished rendering).

Well, this may really be the case. I have to inspect it further, but as you
said my current method should work, I assume you are pointing in the right
direction.

Thanks
Marco

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


Re: When is the UpdateManager definitely available?

Posted by DeWeese Thomas <th...@gmail.com>.
Hi Marco,
   I think your current method should work (unless of course the document isn't dynamic in which case it may never have an UpdateManager).  You might also consider listening to the onload event (either on the document using DOM events, or you can register an SVGLoadEventDispatcherListener with the canvas directly.

   However without knowing your application at all I wonder if possibly the problem isn't listening to early but listening too late, i.e. you request the UpdateManager after it has been discarded (which might happen if you dispose of the document shortly after it has finished rendering).

    Thomas


On Nov 2, 2012, at 9:53 AM, Marco Herrn <ml...@mherrn.de> wrote:

> Hi,
> 
> I must push this mail again.
> It now happened again multiple times to me, that the the method
> canvas.getUpdataManager() returned null when the gvgTreeRenderer completed.
> It happens seldom, but it does happen.
> 
> Please see again the code snipped in the quoted text.
> 
> Is it a bug in batik? According to the javadoc of the getUpdateManager()
> method I would expect that it is guaranteed that getUpdateManager() won't
> return null when being called after being informed of rendering completion.
> 
> Any help appreciated.
> Regards
> Marco
> 
> 
> On Fri, Jul 20, 2012 at 03:38:45PM +0200, ml@mherrn.de wrote:
>> Hi I am using the following code:
>> 
>> canvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
>>        @Override
>>        public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
>>          canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>>        }
>>      });
>> 
>> to do some changes in the DOM of an SVG document. I expected that the
>> updatemanager is definitely available when gvtRenderingCompleted was
>> called.
>> However, it now happened at least once that I got a NullPointerException
>> on the line
>>  canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>> 
>> So it seems that there is still no guarantee that the UpdateManager is
>> available then. Am I missing something? Must I register on a different
>> listener?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


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