List Info

Thread: Re: Performance issue with tablet stylus/pen
Re: Performance issue with tablet stylus/pen
country flaguser name
United Kingdom		 2007-03-21 04:12:23 

  


  

    
kodak.com">thomas.deweesekodak.com wrote:


knotes.kodak.com"
 type="cite">
  

   If I recall correctly I think the Tablet version of Windows is
'mouse move' event happy (presumably for text recog).  This is
probably why it lags on a Tablet but not on other devices.
  



Correct. But the lag is not there in 1.6 stable, where as it is in the
new cut. I've verified that the same amount of mouse move events are
being fired for each version.



knotes.kodak.com"
 type="cite">
  
  

  

    
Question: Has something changed in the update manager (or somewhere else 
    

  

  

  

  

    
like the AnimationEngine) that would cause this performance hit? Here's 
some evidence that suggests that batik is chewing up more CPU cycles in 
this newer version than the 1.6 stable release:
    

  

  

   It wouldn't surprise me if the update manager had extra work to do
to support animations (like update the state of any animation elements
before redrawing the display).


    That said I'm a little surprised you modify the document at all...
If you are drawing in an Overlay you can (and probably should) modify 
the Overlay in the Swing thread.  What are you changing in the Document
that requires you to do your changes in the UpdateManager thread?
  



The drawings need to be saved with the document so that users who
subsequently view the document see them. We don't actually use
repaint() for the overlay at all, so in essence this is just a
disguised Interactor. Each update is done with a mouse up event, which
ultimately executes the following snippet via the update manager:





        final Element stroke = anim.endStroke();
      ;  


   ;     RunnableQueue rq = updateManager.getUpdateRunnableQueue();


  ;      rq.invokeLater(new Runnable() {

 ;           public void run() {


 ;           ;   currScribbleGroup.appendChild(stroke);


    ;        }


 ;       });

After more poking around, I see that there are also updates to the
document on mousedown and mouse drag events, but these do not occur on
the update manager thread, just the mouse up event. I'm not sure if
this is relevant or not though.




  

  
  
   
     
    

  

    Re: Performance issue with tablet
stylus/pen
  


  

     country flaguser name
United Kingdom		
     2007-03-21 05:43:36
  


  

    
Disabling animations right after the document loads seems to
have done 
the trick. See 
http://www.nabble.com/how-to-disab
le-animations-while-processing-t3426595.html 
...Thanks!



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




  


  

    
  

  
  
   
     
    

  

    Re: Performance issue with tablet
stylus/pen
  


  

     user name

     2007-03-21 06:15:29
  


  

    
Hi Martin,

>> thomas.deweesekodak.com wrote:
>> 
>>     That said I'm a little surprised you modify the
document at all...
>> If you are drawing in an Overlay you can (and
probably should) modify 
>> the Overlay in the Swing thread.  What are you
changing in the Document
>> that requires you to do your changes in the
UpdateManager thread?

Martin Constantine <mackawlecture123.com> wrote on
03/21/2007 05:12:23 
AM:

> The drawings need to be saved with the document so that
users who 
> subsequently view the document see them.  We don't
actually use 
> repaint() for the overlay at all, so in essence this is
just a 
> disguised Interactor.

    Uhh, well since the _only_ method in the Overlay
Interface is 'paint'
you don't have an Overlay at all. ;)

    Anyway, I thought you appended everything at the end of
the draw 
action:

Martin Constantine <mackawlecture123.com> wrote on
03/16/2007 06:24:06 
AM:

> Updates to the document occur on mousePressed,
mouseDragged, and 
> mouseReleased. The GVT tree is updated on mouseReleased
where the 
> entire stroke is appended to the current stroke group.

    Drawing the interactive stuff in the overlay is really a
much
better way to handle things.

> Each update is done with a mouse up event, which
ultimately executes 
> the following snippet via the update manager:

    You say a 'mouse up event' but that would be at the end
of all
the drawing.  So which is it?

    BTW if you are appending content that includes your
animation elements then this may account for the extra
overhead
as we now need to locate all those elements and parse them
and
add them to the animation timeline.

    Where is the 'lag'?  Is it while drawing or after the
user draws and the items are added to the canvas?

>         final Element stroke = anim.endStroke();
> 
>         RunnableQueue rq =
updateManager.getUpdateRunnableQueue();
>         rq.invokeLater(new Runnable() {
> 
>             public void run() {
>                currScribbleGroup.appendChild(stroke);
>             }
>         });
> After more poking around, I see that there are also
updates to the 
> document on mousedown and mouse drag events, but these
do not occur 
> on the update manager thread, just the mouse up event.
I'm not sure 
> if this is relevant or not though.


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




  


  

    
  

  
  
   
     
    






 [1-3]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )