Hello strk, Monday, October 9, 2006, 11:10:03 AM, you wrote: s> I don't think there's any such support. s> For 'visible' changes I think there's some transparent support s> trough the different GUIS, but the 'stopped movie' handling (and s> also backgrounds) I think is missing.
Hmm, don't know what you mean by "transparent support". I think my original post wasn't very clear (I should read back what I write *g*). s> I've been thinking about this from the start, but I'm not really s> a graphic person, so wouldn't know how to proceed. s> My idea was to keep all layers in seperate "drawables" and overlay s> them as needed. Probably the "caching" feature does something similar s> anyway. I was think of something like this: - Each character instance gets a invalidate() method and a m_invalidated flag. - When calling invalidate() it checks the flag. If it isn't set then it does so and calls invalidate() of the parent. - invalidate() is called whenever the character changes in a visible manner (frame advance, matrix change, variable update, ...). This is probably the most important part to make it work. Because of the recursion the main movie instance gets the flag set whenever something happened. With other words, when the movie is stopped it won't be set. (BTW, could this be related to the 100% CPU issue? On slow computers Gnash will currently probably take up much CPU even if the movie is stopped.) Obviously the flags show what instances have been changed in the movie so it should be easy to determine which parts of the screen need to be updated. Don't know at the moment if the instance class has already a method to calculate the real boundaries of a character. I know Flash is smart enough to find very distant updates. That means, when you have a small updating sprite in the upper left corner and another one in the opposite corner, it will create two small, different update regions instead of redrawing the whole frame. At the other hand, it is too dump to avoid redrawing of hidden objects (_visible=false). ;-) I think this should not be difficult to implement... Udo _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
