gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog server/character.h server/dlist...


From: Sandro Santilli
Subject: Re: [Gnash-commit] gnash ChangeLog server/character.h server/dlist...
Date: Tue, 30 Oct 2007 15:00:23 +0100

On Tue, Oct 30, 2007 at 02:54:57PM +0100, Udo Giacomozzi wrote:
> Hello Sandro,
> 
> Tuesday, October 30, 2007, 10:51:09 AM, you wrote:
> SS> I'll add a TODO item in the DisplayList::add_invalidated_bounds.
> SS> Another thing I noticed is the tree crawling in DisplayList::display
> SS> (now I guess that's also in ::add_invalidated_bounds) which sounds
> SS> suspicious performance-wise.
> 
> You are talking about display() recursively calling the same method of
> the childs? Seems the only way to do it to me...
> And what performance problem do you see?

Yes, it's the parent's scan.
If we had two distinct functions (or an additional argument to display)
we shouldn't need to do that scan, right ?
We'd know from the start wheter we're calling ::display because we're
rendering a character as mask or not.
No, I don't really see the performance problem, just that code hit
my attention. 

> SS> Was thinking maybe we could have two functions:
> 
> SS> ::display
> SS> ::renderAsMask
> 
> passing the mask child to renderAsMask() ? I doubt that would work..

The mask itself, which would call renderAsMask on its childs as well.

> Which way goes the reference between mask and maskee? The mask having
> a reference to the maskee or vice-verse?

The maskee have a reference to the mask.

> If the maskee has the reference to the mask, then it would be simple:
> 
> - (in dlist.cpp) when a child is found with a mask reference:
> - beginMask
> - call display() of the mask instance
> - endMask
> - call display() of the maskee
> - disableMask
> 
> Just guessing...

It's already implemented, is the original mail in this thread :)

--strk;




reply via email to

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