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 Br...@andovercontrols.com on 2002/08/14 15:15:51 UTC

Repaint Problems

Hello - 

There's a bug I have with JSVGCanvas that I'd appreciate help with.

I'm developing a WYSIWYG SVG editor using Batik and Java.  Basically what we have is an MDI environment with multiple JInternalFrame objects, each of which displays a JSVGCanvas.  There's a list of SVG templates we call controls on the left side of the screen.  The user can drag templates onto a canvas, then drag them around to move them, rotate them, and scale them using a selection box (done through SVG).

The problem is that when the user drags controls around, everything seems to work fine.  But then as soon as the GUI calls repaint(), the off-screen buffer is redrawn, and for whatever reason, this buffer has not updated its state.  So the buffer has all sorts of garbage on it from times when a control was in a different spot than it is now.  In other words, it's not clean..it wasn't cleared before it was repainted.  Even though the screen itself was fine before the repaint, the offscreen buffer image was not.  

This must be an internal problem, right?  I'm not sure how to correct this, but I'd appreciate some help.  I'd rather not have to hack around this sort of thing...

Thanks!

- Mike Braude
------------------------------------------------------------------------------------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains information of Andover Controls Corporation and or Andover Controls LTD. which may be confidential, proprietary, copyrighted and/or legally privileged. This Email is intended solely for the use of the individual or entity named on the message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it.

==============================================================================



Repaint Problems

Posted by Thomas E Deweese <th...@kodak.com>.
Hi Braude,

   First some general questions,

   What version of Batik?  If not current CVS you might try that
(although I don't think any real changes have been made in this area).

   What platform?

   What JDK?

>>>>> "BM" == BraudeM  <Br...@andovercontrols.com> writes:

BM> There's a bug I have with JSVGCanvas that I'd appreciate help
BM> with.

BM> I'm developing a WYSIWYG SVG editor using Batik and Java.
BM> Basically what we have is an MDI environment with multiple
BM> JInternalFrame objects, each of which displays a JSVGCanvas.
BM> There's a list of SVG templates we call controls on the left side
BM> of the screen.  The user can drag templates onto a canvas, then
BM> drag them around to move them, rotate them, and scale them using a
BM> selection box (done through SVG).

BM> The problem is that when the user drags controls around,
BM> everything seems to work fine.  But then as soon as the GUI calls
BM> repaint(), the off-screen buffer is redrawn, and for whatever
BM> reason, this buffer has not updated its state.  So the buffer has
BM> all sorts of garbage on it from times when a control was in a
BM> different spot than it is now.  In other words, it's not clean..it
BM> wasn't cleared before it was repainted.  Even though the screen
BM> itself was fine before the repaint, the offscreen buffer image was
BM> not.

    I've never seen this in Squiggle (the SVG browser).  Since you
haven't described anything that I haven't done with plain SVG (add
elements, move elements around etc) I'm not sure where the problem
would come from.  One idea I have is that if the document becomes
'smaller' the renderer won't paint or update the parts of the old
buffer that are no longer covered by the document any more

BM> This must be an internal problem, right?  I'm not sure how to
BM> correct this, but I'd appreciate some help.  I'd rather not have
BM> to hack around this sort of thing...

    I wouldn't rule it out as an internal problem, but I suspect
the responsability is shared :)  

    It might also be useful to send a screen snap of the dirty stuff.

    Obviously, a standalone app that reproduces the problem would be
ideal.

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