gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] bounds_in_clipping_area bug


From: strk
Subject: Re: [Gnash-dev] bounds_in_clipping_area bug
Date: Mon, 11 Feb 2008 11:41:46 +0100

On Mon, Feb 11, 2008 at 11:26:11AM +0100, Udo Giacomozzi wrote:
> Hello strk,
> 
> Friday, February 8, 2008, 5:40:16 PM, you wrote:
> s> I attached the .as files and .swf files to this bug item:
> s> https://savannah.gnu.org/bugs/index.php?22258
> 
> Seems that the problem is solved now?

Yes thanks. The loading mechanism was bogus.
It turns out when you call loadMovie agains a sprite
and then unload the sprite, the movie is still loaded
only if a new sprite with same target as old one is
available at load time (one frame after the request).

> I anyway think that this code is useless, so I removed it from
> sprite_instance and improved generic_character instead. This
> simplifies the code and probably offers slightly better performance
> for movies with complex display lists.

Did you take care of masks ? both dynamic and layer ones ?
I mean, if a mask is out of the clipping area, we still want
to display it IFF the display is meant to construct the "mask",
right ?
OR, we may skip it's rendering as far as we also skip rendering
of any maskee..

> A question about do_display_callback(): What is it's purpose? With the
> old implementation it wasn't called unless the character has been
> rendered (changed) in that frame. Now it is called in each frame for
> each character (seems more correct to me since it would be done that
> way without invalidated bounds optimization).

It is probably unused old code, I'd drop it if nobody else
has an hint about it.

> Anyway, I would like to know the effects of missing calls to
> NON-rendring calls in display() implementations.

IIRC I tested this a bit in the past with the 'skip-rendering-if-late'
patch. Actually, it should still be in head, switched by a compile-time
macro in gui.cpp.
It would skip movie_root::display as a whole..

--strk;





reply via email to

[Prev in Thread] Current Thread [Next in Thread]