Tue 04 Mar 2008 11:05:09 AM UTC, comment #14:
Committed args checking in the drawing api (both head and branch).
|
Tue 04 Mar 2008 10:12:32 AM UTC, comment #13:
It turns out the NaN originates from a MovieClip.lineTo() call,
we use as_value::to_number() there, as we're interested in decimal
numbers, but never check for NaN.
I'll add a testcase for this in DrawingApiTest and all checks in the drawing api.
Would like to see the wallpaper patch reverted for proper testing.
|
Tue 04 Mar 2008 07:45:44 AM UTC, comment #12:
I think we should find out where the NaN is generated.
Parser reads ints, so I guess NaN can only be the result
of a matrix transformation, which will need to use floats
to reduce loss of precision.
Also, cairo doesn't choke on that input.
Did you handle to isolate the offending shape ?
Would be worth having in our testsuite...
|
Tue 04 Mar 2008 05:50:17 AM UTC, comment #11:
I've committed a type safe implementation of isnan in HEAD.
|
Tue 04 Mar 2008 12:21:49 AM UTC, comment #10:
I've committed a wallpaper fix in HEAD, and I'll do the same in the -rc branch. Leaving this open for the real fix (changing paths to use ints).
|
Mon 03 Mar 2008 10:33:43 PM UTC, comment #9:
I confirm that int to float conversion is to blame.
I wrote a patch a while ago that changes paths to use ints instead of floats. My build with this patch shows the movie to render fine with AGG. I guess this patch is now higher priority.
Another thing to consider is that this patch is not a small patch. So it probably is not suitable to apply to the release branch. Yet I do not have a quick fix for the branch.
|
Mon 03 Mar 2008 10:05:29 PM UTC, comment #8:
I now believe that patch to be bogus, because our implementation of isnan is not valid. However, I believe the analysis is correct in that the renderer receives a NaN coordinate. I suspect the float to int conversion we do currently is to blame.
|
Mon 03 Mar 2008 09:06:10 PM UTC, comment #7:
all the values checked for isnan() are integers,
dunno how can that assertion fail (but I confirm it does..)
|
Mon 03 Mar 2008 08:47:13 PM UTC, comment #6:
Turns out the problem is in the parser. The parser apparently feeds some floats into the shape definition which are NaN. Neither AGG nor OpenGL are equipped to deal with such numbers. The attached patch shows the problem in the parser.
(file #15167)
|
Mon 03 Mar 2008 08:13:49 PM UTC, comment #5:
It's probably worth noting that the OpenGL renderer uses its own algorithm for curve interpolation (that has been in Gnash for years) while Cairo and AGG have specialized methods for this purpose.
|
Mon 03 Mar 2008 01:42:33 PM UTC, comment #4:
the GL backend seems to engage a recursive call too..
#0 0xb75017ba in sqrtf () from /lib/tls/i686/cmov/libm.so.6
#1 0x08067962 in gnash::trace_curve (startP=@0xbfdcd930, controlP=@0xbf5d1108, endP=@0xbf5d10f8, coords=@0xbfdcda64)
at /home/strk/src/gnash/gnash-head/libgeometry/Point2d.h:140
#2 0x08067a15 in gnash::trace_curve (startP=@0xbfdcd930, controlP=@0xbf5d1198, endP=@0xbf5d1188, coords=@0xbfdcda64)
at /home/strk/src/gnash/gnash-head/backend/render_handler_ogl.cpp:247
#3 0x08067a15 in gnash::trace_curve (startP=@0xbfdcd930, controlP=@0xbf5d1228, endP=@0xbf5d1218, coords=@0xbfdcda64)
at /home/strk/src/gnash/gnash-head/backend/render_handler_ogl.cpp:247
#4 0x08067a15 in gnash::trace_curve (startP=@0xbfdcd930, controlP=@0xbf5d12b8, endP=@0xbf5d12a8, coords=@0xbfdcda64)
at /home/strk/src/gnash/gnash-head/backend/render_handler_ogl.cpp:247
#5 0x08067a15 in gnash::trace_curve (startP=@0xbfdcd930, controlP=@0xbf5d1348, endP=@0xbf5d1338, coords=@0xbfdcda64)
at /home/strk/src/gnash/gnash-head/backend/render_handler_ogl.cpp:247
|
Mon 03 Mar 2008 01:00:19 PM UTC, comment #3:
On the other hand, opengl renderer segfaults..
|
Mon 03 Mar 2008 12:30:38 PM UTC, comment #2:
I confirm cairo renderer is able to render the first frame
|
Mon 03 Mar 2008 12:16:47 PM UTC, comment #1:
Running with -r0 doesn't seem to kill CPU.
gdb shows gnash busy in:
agg::curve3_div::recursive_bezier ()
|
Mon 03 Mar 2008 11:49:14 AM UTC, original submission:
http://faraday.physics.utoronto.ca/PVB/Harrison/Flash/ClassMechanics/MotionDiagram/MotionDiagram.swf
version: SWF6
md5: dfce34df33f0172b18cc7fd9c59c274c
Gnash never handles to render the first frame.
Or maybe it will waiting more, but CPU is at 100% quickly and
doesn't get down. 12 FPS nominal rate.
|