[Top][All Lists]
[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
multi-inv-test.swf
Description: application/shockwave-flash
multi-inv-test2.swf
Description: application/shockwave-flash
multi-inv-test3.swf
Description: application/shockwave-flash