gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash backend/render_handler.h backend/render_h...


From: Udo Giacomozzi
Subject: Re: [Gnash-commit] gnash backend/render_handler.h backend/render_h...
Date: Wed, 28 Feb 2007 18:46:18 +0100

Some comments on this large commit:

Main reason was to dump get_invalidated_bounds() and introduce a more
abstract add_invalidated_bounds() which just passes it's bounds to a
class (SnappingRanges2d) which is solely responsible what it does with
this information.

I changed the name to avoid any confusion.

Of course this change required lots of changes in the server/
directory, but mostly syntax changes were involved - it should behave
exactly as it did before.

The new SnappingRanges2d class can work in two modes. In "single_mode"
it works just like Gnash worked before this commit. In multi mode, it
tries to combine ranges whenever it thinks it's appropriate. Whenever
a different algorithm is needed we can implement it using this class.

SnappingRanges2d has a getFullArea() function which returns a single
Range2d for any parts in Gnash that don't support multiple ranges yet
(MovieTester for example).

Of course GUI and renderers had to be adapted, too. FB-AGG and GTK-AGG
should work (and they support multi ranges). I'm not sure about
FLTK-AGG (and other -AGG combinations). OpenGL and Cairo did never
care about invalidated bounds, AFAIK, so should continue to work.
Sorry, but I could not check this.

I also dropped the additional 2 pixels for AGG anti-aliasing. Probably
it's not required (will check this further).

Check the attachments for an before/after comparison.

test1 demonstrates two distinct inv. bounds which become one when both
      stars approach the center. Old implementation would use a
      growing and shrinking range.

test2 shows 150 randomly placed stars, which will lead to 1-3 bounds.
      This shows that SnappingRanges2d effectively merges bounds.

test3 shows 5 stars rotating around their common center. Performance
      is more than 10 times better now.

Possible drawbacks: display_glyph can't currently find out the size of
a single (text) character and is forced to re-render the glyph for all
clipping bounds. This can reduce performance for movies with *lots* of
text and *lots* of ranges.

BTW, I had to convert between Range2d<> and rect back and forth. We
should really use only one class!

Testcases will follow...

Udo

Attachment: multi-inv-test.swf
Description: application/shockwave-flash

Attachment: multi-inv-test2.swf
Description: application/shockwave-flash

Attachment: multi-inv-test3.swf
Description: application/shockwave-flash


reply via email to

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