>>>>> "B" == BraudeM <[EMAIL PROTECTED]> writes:
B> I sent a mail out before but only got one response. Somebody's got
B> to know what's going on here....I really need some help.
You never responded to my response which had four or five requests
for more information. In particular a small screen shot of the dirty
stuff would be useful to see (can email directly if you can't get size
down).
B> I'm building an SVG WYSIWYG editor using batik 1.5 with the jdk
B> 1.3.
Which Batik 1.5? Beta 1, 2, or 3?
If it's not '3' please upgrade.
B> The user drags SVG shapes onto an SVGCanvas, and can drag, rotate,
B> and scale the shapes. The code's pretty simple -
B> if(selectionManager.isSelected(controlNode))
B> selectionManager.positionSelectionBox(controlNode);
This is interesting. How does the selectionManager draw it's
selection box?
B> public static void setTransform(Element controlNode,
B> AffineTransform transform) {
[...]
B> controlNode.setAttributeNS(null, SVG_TRANSFORM_ATTRIBUTE,
B> matrixTransform);
Just as an FYI, I do this all the time through ECMA script. So
there is something else that is effecting behaviour. One thing just
occured to me, does this stuff have filters? We don't properly
account for filters in our bounds calculations right now.
B> This is the code that gets called when I want to move a shape
B> around on the canvas...it works, but it seems to me that there's an
B> error with the dirty rect caclulations, because when the canvas
B> gets repainted, I see little splotches of the shapes all around the
B> canvas. I don't know what's going on. The problem only occurs
B> when repaint is called.
Sure, but repaint being called is very common, as it happens when
ever another window damages part of the Java window, or when the
window is resized. Even when you pan in the Canvas it is redrawing
the entire offscreen buffer. None of these cause the dirty bits to be
displayed in straight Squiggle.
Are you using Double Buffered rendering or single buffered (if you
don't do anything, by default JSVGCanvas has double buffering off).
B> Somebody suggested that perhaps its a size issue, but I am setting
B> the dimension of the SVG to be more than large enough. While
B> debugging, I've proven that it's the renderer.getOffScreen() that's
B> causing the problem. This is the image that's all jumbled
B> up....before repaint is called, I'm assuming the rendering system
B> is only updating the part of the screen that's been changed..but
B> the underlying buffer is not repainted properly.
If you are using single buffer it generally is not a good idea to
just call renderer.getOffScreen() as you are likely to get the buffer
in the middle of a rendering request (which will have some dirty bits
in it although they should only one frames worth of dirty bits, you
seem to be describing more than that).
B> Please, I'd appreciate any suggestions or help anybody can offer
B> me. I've spent a significant amount of time trying to fix this and
B> haven't made any progress.
As I pointed out in my other message most of what you have
described is done all the time without the side effects you have. So
to help you we need to know more about your code. In particular I'd
be curious to know more about your selectionManager. Does it plug
into Batik's overlay framework? Is it another SVG element that is
moved around (if so how? are filters involved?)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
