You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Cameron McCormack <ca...@mcc.id.au> on 2006/12/28 07:05:17 UTC
One pixel high rendering anomaly
Hi.
http://www.w3.org/Graphics/SVG/Test/20061213/svg/animate-elem-04-t.svg
tests motion animation, where the blue triangle moves from the left pink
box to the one on the right. I notice under Linux that as the triangle
moves over the right pink box, there is some strange rendering just at
the top of the triangle. It’s as if the image it is compositing with
underneath (the pink box) is being sampled at one pixel below where it
should be. Here’s a screenshot just before the animation finishes:
http://arc.mcc.id.au/temp/2006/render.png
This occurs under Linux JREs 1.4, 1.5 and 1.6, but not under Linux 1.3.
If I set shape-rendering to anything other than auto, the problem
disappears.
I tried under Apple’s OS X JRE 1.5 and the rendering artiface doesn’t
appear. I haven’t tested it under Windows.
What might the problem be?
Thanks,
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: One pixel high rendering anomaly
Posted by Cameron McCormack <ca...@mcc.id.au>.
Cameron McCormack:
> I think the same problem occurs on this test file:
>
> http://www.w3.org/Graphics/SVG/Test/20061213/svg/animate-elem-33-t.svg
>
> but here it’s much more obvious:
>
> http://arc.mcc.id.au/temp/2006/render2.png
>
> The left few pixels of the circle at the many animation ticks in the top
> left shouldn’t be there. Also, in the other three parts of the test,
> the red circle still should only be displayed at the rightmost position.
Actually, according to the test, the circles should end up at the
position indicated with the “4”, but there’s a bug in animation freezing
which makes it think it should be at the rightmost position.
Once the rendering problems are shown, pressing Ctrl+T seems to clear
them by re-rendering the whole canvas.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: One pixel high rendering anomaly
Posted by Cameron McCormack <ca...@mcc.id.au>.
Thomas DeWeese:
> This definitely looks like a bug in the dirty region management
> (see batik.gvt.UpdateTracker). However, the GVT tree should track
> this stuff automatically.
>
> In the past bugs along these lines have shown up when an element
> changes it's bounds and then a higher level group's transform
> changes or the like (this is a tricky case because if the higher
> group just dirties it's current bounds it won't include the old
> bounds of the shape).
I tracked down the problem. It only occurred with motion animation, and
it was because I didn’t make a copy of the AffineTransform I got from
the SVGMotionAnimatableElement before I called setTransform on the
GraphicsNode (in AbstractGraphicsNodeBridge.computeTransform).
Fixed in SVN now.
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: One pixel high rendering anomaly
Posted by th...@kodak.com.
Hi Dieter, Cameron,
"Dieter von Holten" <in...@dvholten.de> wrote on 12/30/2006 03:11:54 AM:
> i saw stuff like that when i did animation with graphics2D a while ago.
> the smear-effect comes from updating the position of the moving object
> indepently of the drawing.
This definitely looks like a bug in the dirty region management
(see batik.gvt.UpdateTracker). However, the GVT tree should track
this stuff automatically.
In the past bugs along these lines have shown up when an element
changes it's bounds and then a higher level group's transform
changes or the like (this is a tricky case because if the higher
group just dirties it's current bounds it won't include the old
bounds of the shape).
> i suspect a problem deep in the repaint-stuff: on my todo-list i have
some
> strange rendering effects from script-generated animations. the thing to
> investigate is not a smear-effect, but it seems, that the last update is
not
> painted (the script stops when done and somehow prevents the last
repaint or
> update).
Hmm, sounds like something very odd. Is it possible the script isn't
returning for some reason? Also are you viewing this in the canvas or
some other way?
> The way i try to debug this is 'unusual': this worked long ago. So i get
> older versions from svn to find that delta, which introduced the
problem..
This is actually a common debugging technique and just one example of
why good revision control is so important.
> Seems, regard was/is not used too often.
Is there a regression in this area? I just went through
and looked at everything and there were a few 'odd' results
I don't recall anything in this area...
Re: One pixel high rendering anomaly
Posted by Dieter von Holten <in...@dvholten.de>.
hi cameron,
i saw stuff like that when i did animation with graphics2D a while ago.
the smear-effect comes from updating the position of the moving object
indepently
of the drawing. Lets say the animation decides to put the circle at x,y. it
calls repaint(),
which queues the request with a current dirty rectangle. Then, before the
pixels are updated,
the position of the circle is changed again. Then, when it is time for
screen-update, the area
of the original request and the current position dont match - that leaves
some pixel from the
previous paint.
(the background of the remainders isnt repainted because it isnt considered
dirty).
The effect should be different, when the code is executed ( 'executed' -
word of the day...)
on a single or multi-core cpu.
i suspect a problem deep in the repaint-stuff: on my todo-list i have some
strange rendering effects from script-generated animations. the thing to
investigate is not a smear-effect, but it seems, that the last update is not
painted (the script stops when done and somehow prevents the last repaint or
update).
The way i try to debug this is 'unusual': this worked long ago. So i get
older versions from svn to find that delta, which introduced the problem..
Seems, regard was/is not used too often.
But thats for next year - which is quickly approaching.
Happy New Year
dieter
----- Original Message -----
From: "Cameron McCormack" <ca...@mcc.id.au>
To: <ba...@xmlgraphics.apache.org>
Sent: Friday, December 29, 2006 1:45 AM
Subject: Re: One pixel high rendering anomaly
> I think the same problem occurs on this test file:
>
> http://www.w3.org/Graphics/SVG/Test/20061213/svg/animate-elem-33-t.svg
>
> but here it’s much more obvious:
>
> http://arc.mcc.id.au/temp/2006/render2.png
>
> The left few pixels of the circle at the many animation ticks in the top
> left shouldn’t be there. Also, in the other three parts of the test,
> the red circle still should only be displayed at the rightmost position.
>
> --
> Cameron McCormack, http://mcc.id.au/
> xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: One pixel high rendering anomaly
Posted by Cameron McCormack <ca...@mcc.id.au>.
I think the same problem occurs on this test file:
http://www.w3.org/Graphics/SVG/Test/20061213/svg/animate-elem-33-t.svg
but here it’s much more obvious:
http://arc.mcc.id.au/temp/2006/render2.png
The left few pixels of the circle at the many animation ticks in the top
left shouldn’t be there. Also, in the other three parts of the test,
the red circle still should only be displayed at the rightmost position.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org