Sat 02 Dec 2006 09:31:09 PM UTC, comment #9:
Added more uses for the Range2d<> lately.
It's needed for better readability and for safer operations.
I don't get any problem with scale at all, anyway yes, I think properly initializing the scale would be nice.
BTW, the SDL black screen isn't fixed for me with your patch,
let's keep this discussion on bug #18425
|
Sat 02 Dec 2006 01:58:30 AM UTC, comment #8:
This change to the render_handler_agg constructor fixed this problem for me:
xscale(1.0 / 20.0), // (1.0),
yscale(1.0 / 20.0), // (1.0),
The Range2d substitution for m_clip_... wasn't needed for me.
|
Fri 01 Dec 2006 04:44:54 PM UTC, comment #7:
Ok, I committed a temporary hack to fix this in set_invalidater_region.
Basically I'm using a Range2d<int> temporary object.
I'm doing this so you can see a use case, best approach
is substituting Range2d<int> to the current m_clip_{x,y}{min,max}.
|
Fri 01 Dec 2006 03:41:41 PM UTC, comment #6:
Udo, I committed the new Range2d templated class.
You can now use that for your bounds in agg, and use
the Intersection function to "clamp" invalidated rect
to display area.
You'd likely change the world_to_pixel function to
take a gnash::rect and return a gnash::geometry::Range2d<int>
for this to work.
Let me know if you want me to do that.
|
Fri 01 Dec 2006 09:36:24 AM UTC, comment #5:
found the bug, in agg renderer:
if (m_clip_xmin < 0) m_clip_xmin=0;
if (m_clip_ymin < 0) m_clip_ymin=0;
if (m_clip_xmax > xres-1) m_clip_xmax = xres-1;
if (m_clip_ymax > yres-1) m_clip_ymax = yres-1;
the code above does not handle the case where the minimun values are bigger then the upmost limit or the maximum values are smaller
then the downmost limit.
The function to use for 'clamping' the 4 corners in the visible
area is fclamp(y{min,max}, 0, yres-1) and fclamp(x{min,max}, 0, xres-1).
This is assuming that 'world' space coordinates can have arbitrary values.
Udo, I'll fix this, but later I'd like to turn m_clip_{x,y}{min,max} into a gnash::rect, where gnash::rect
will become a templated class to allow for using 'int'
instead of 'floats' (template parameter would be the type
of ordinate value). Using a rect will make the code easier
to read and safer in that you will be able to use gnash::rect
methods for doing an intersection between the given boundaries
andn the displaied boundaries.
|
Thu 30 Nov 2006 10:16:56 PM UTC, comment #4:
The file: http://weebls-stuff.com/toons/flash/6964trev3c.swf
md5sum 2dfa9218bdbced5a8680b03cb8ec03a4
Udo I think we already discussed a similar case in the past,
ie: a character that when you click on it disappears from stage.
My gut feeling is that this movie is triggering this case
(try double click - with different timings - on the PLAY text)
|
Thu 30 Nov 2006 09:08:57 PM UTC, comment #3:
I think I'm closer. With Loader thread disabled it looks like it's a 'double click' on the Play text that triggers this.
It is possible this is due to a character being deleted by first click while references to it are still laying around at second click..
|
Thu 30 Nov 2006 08:43:56 PM UTC, comment #2:
Playing the same movie multiple time, and pressing the "PLAY"
button at different time-distance from appearing, I get
different value in this warning:
clear_framebuffer() called with height=-22
Everytime the value is negative, as in the case above,
the segfault happens.
|
Thu 30 Nov 2006 04:09:01 PM UTC, comment #1:
It seems that disabling loader thread still triggers this.
Seems related to button events, so maybe there are
two concurrent advance_movie() running: one from the 'FPS' timer
and another from the 'user event' trigger.
Asking because even with loader thread disabled the bug
is not always raised.
Backtrace is still similar:
#0 0xb796742a in agg::pixfmt_alpha_blend_gray<agg::blender_gray<agg::gray8>, agg::row_accessor<unsigned char>, 1u, 0u>::copy_hline (this=0x8803998, x=283,
y=722, len=16, c=@0xbfba97e6) at agg_pixfmt_gray.h:257
257 *p = c.v;
(gdb) bt
#0 0xb796742a in agg::pixfmt_alpha_blend_gray<agg::blender_gray<agg::gray8>, agg::row_accessor<unsigned char>, 1u, 0u>::copy_hline (this=0x8803998, x=283,
y=722, len=16, c=@0xbfba97e6) at agg_pixfmt_gray.h:257
#1 0xb79674b7 in gnash::agg_alpha_mask::clear (this=0x8803980, left=283, top=0, width=16, height=4294967271)
at /home/strk/src/gnash/gnash-head/backend/render_handler_agg.cpp:287
#2 0xb7989b29 in gnash::render_handler_agg<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb<agg::rgba8, agg::order_rgb>, agg::row_accessor<unsigned char> > >::begin_submit_mask (this=0x80c4b98) at /home/strk/src/gnash/gnash-head/backend/render_handler_agg.cpp:661
#3 0xb7811ad2 in gnash::render::disable_mask () at /home/strk/src/gnash/gnash-head/server/render.cpp:238
#4 0xb77f0992 in gnash::DisplayList::display (this=0x80e36a0) at /home/strk/src/gnash/gnash-head/server/dlist.cpp:510
#5 0xb77bd65a in gnash::sprite_instance::swap_characters (this=0x80e35e8, ch1=0x0, ch2=0x0)
|
Wed 29 Nov 2006 11:27:11 PM UTC, original submission:
This is with movie 6964trev3c.swf (magical trevor).
I'm sure is attached to some bug report here, just dunno how to search for it.
Anyway, the segfault does NOT always raise, and seems related to timing. The culprit seems to be in agg_alpha_mask::clear being called with an absurdly big height argument.
BTW, gnash invoked with -v also show:
00:26:13: warning: clear_framebuffer() called with height=-8
Which is likely to translate to 4294967274 in unsignedland.
(gdb) bt
#0 0xb78ca42a in agg::pixfmt_alpha_blend_gray<agg::blender_gray<agg::gray8>, agg::row_accessor<unsigned char>, 1u, 0u>::copy_hline (this=0x87cac40, x=283, y=722, len=16, c=@0xbfb0e846) at agg_pixfmt_gray.h:257
#1 0xb78ca4b7 in gnash::agg_alpha_mask::clear (this=0x87cac28, left=283, top=0, width=16, height=4294967274)
at /home/strk/src/gnash/gnash-head/backend/render_handler_agg.cpp:287
#2 0xb78ecb29 in gnash::render_handler_agg<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb<agg::rgba8, agg::order_rgb>, agg::row_accessor<unsigned char> > >::begin_submit_mask (this=0x80c4b98)
at /home/strk/src/gnash/gnash-head/backend/render_handler_agg.cpp:661
|