[kepler-dev] problems with annotations
cxh at eecs.berkeley.edu
Wed Oct 26 08:01:17 PDT 2005
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.
>> 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
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
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.
> would the new util.EmptyChangeRequest class help? If you issue an emp
> change request, are the ports added to the XML? May be worth a try
> Chad Berkley wrote:
> > Hey Matt and Shawn,
> > In looking into the problem of getting the port attributes (mainly
> > semantic types) to propegate through new kar files, I've run into a
> > fundamental problem with the way PTII handles ports on the canvas.
> > <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
> > the xml view, there are no moml ports included. This is true until
> > actually change a port property, then it updates the model with the
> > information. The problem with this is, even though i'm now adding
> > port semantic types to the moml in the kar file, they don't show up
> > shawn's semantic type editor until you actually edit the port. I'm
> > 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
> > ending up with two annotations per actor. This will probably get f
> > 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
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev