[kepler-dev] problems with annotations

[Christopher Brooks]

Hi Matthew,

This seems like a threading/rendering problem is much like how icon
gifs are handled.  The problems we've seen are that reading an image
will spawn a thread (I think) that reads the icon and the rendering of
the rest of the block diagram proceeds and then the image is finally
read and then there are problems.  So, you might examine how images
are handled and see if that does anything for you.

One thing to check on is that your calls are either in the Swing
thread or you are creating a Runnable and calling
SwingUtilities.invokeLater().   Placing calls to
SwingUtilities.isEventThread() can be illuminating.

One other approach would be to halt the rendering if you see a 
SVG icon and wait for it to complete.  This is sort of gross.
Another would be to somehow cache the SVG icon size so that the
ports end up in right place.

Your design of using EmptyChangeRequest seems reasonable, though
it seems to point out a bug in the Ptolemy code.

_Christopher

--------

    Christopher -
    
     >> BTW, I'm nervous that util.EmptyChangeRequest is required at all.
    
    me too :-)  Let me explain what the problem is, and maybe you can 
    suggest another, more-elegant way to fire such an update...
    
    I've hooked up the Apache Batik SVG rendering framework so that it 
    handles the rendering of SVG icons. This included overriding 
    ptolemy.vergil.icon.XMLIcon and diva.canvas.toolbox.SVGParser (code not 
    yet in CVS) so that when XMLIcon calls SVGParser.createPaintedList(), it 
    gets back a list contining a diva.util.java2D.SVGPaintedObject (code in 
    kepler cvs under src/exp/).
    
    However, when the code that draws the actor ports calls 
    SVGPaintedObject's "getBounds()" method, the svg icon's size is not yet 
    known (since Batik's rendering process takes a little longer than the 
    current setup). Consequently, getBounds() returns a default value, and 
    the ports are initially drawn somewhere on top of the actor, in the 
    wrong places.
    
    Finally, when Batik has finished rendering, it does a callback to a 
    listener in XMLIcon, which then needs to somehow make the port-rendering 
    code redraw the ports in the correct places (by calling 
    SVGPaintedObject's getBounds() method again, which will now return the 
    real icon size).
    
    So, EmptyChangeRequest was the only way I could find to fire this port 
    redraw. Any suggestions as to how it would be better accomplished are 
    most welcome
    
    Thanks
    
    M
    
    -- 
    
    ---------------------------------------------
    Matthew Brooke, Ph.D.
    Marine Sciences Research Building, Room #3407
    University of California
    Santa Barbara, CA  93106-6150
    ph: (805) 893-7108   fx: 805-893-8062
    brooke at nceas.ucsb.edu
    ---------------------------------------------
    
    Christopher Brooks wrote:
    > Hi Matthew,
    > 
    > BTW, I'm nervous that util.EmptyChangeRequest is required at all.
    > This could indicate some flaw where ChangeRequests are not being
    > created or handled properly.
    > 
    > I don't have concrete evidence of this, just a gut level feeling.
    > 
    > _Christopher
    > 
    > --------
    > 
    >     
    >     would the new util.EmptyChangeRequest class help? If you issue an emp
   ty 
    >     change request, are the ports added to the XML? May be worth a try
    >     
    >     m
    >     
    >     
    >     Chad Berkley wrote:
    >     > Hey Matt and Shawn,
    >     > 
    >     > In looking into the problem of getting the port attributes (mainly 
   the 
    >     > semantic types) to propegate through new kar files, I've run into a
    
    >     > fundamental problem with the way PTII handles ports on the canvas. 
    The 
    >     > <port> entity is not actually added to the model until the port is 
    >     > changed.  Hence, when you drag an actor to the canvas, if you look 
   at 
    >     > the xml view, there are no moml ports included.  This is true until
    you 
    >     > actually change a port property, then it updates the model with the
    port 
    >     > information.  The problem with this is, even though i'm now adding 
   the 
    >     > port semantic types to the moml in the kar file, they don't show up
    in 
    >     > shawn's semantic type editor until you actually edit the port.  I'm
    not 
    >     > sure what to do about this.  any ideas?
    >     > 
    >     > Shawn, another bug I found is that the sms system isn't using the 
    >     > semanticTypeX properties that i had in the actor metadata.  Instead
   , 
    >     > it's creating another property called _semType.  Because of this, w
   e're 
    >     > ending up with two annotations per actor.  This will probably get f
   ixed 
    >     > when you update the sms stuff, right?
    >     > 
    >     > chad
    >     > _______________________________________________
    >     > Kepler-dev mailing list
    >     > Kepler-dev at ecoinformatics.org
    >     > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/keple
   r-dev
    >     _______________________________________________
    >     Kepler-dev mailing list
    >     Kepler-dev at ecoinformatics.org
    >     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-
   dev
    > --------
--------