[Top][All Lists]

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

Re: [Gnash-dev] address@hidden: [AGG] A big optimization to gradient_li

From: Wei Cao
Subject: Re: [Gnash-dev] address@hidden: [AGG] A big optimization to gradient_linear_color]
Date: Wed, 20 May 2009 00:33:21 +0800

hi, all
I improve my caching methods by using rasterizer only when creating the bitmap cache, after the cache is created, I will always use alpha blending operations to fill the intersection area of subshape's bound and clip bounds.
Cache has been added in draw_glyph, draw_shape and draw_mask_shape.
Performance gain is perfect, about half of the execution time has been cut down for nearly all flash files I have seen.
for example , the five swf files on,
Flash                         Executation time
                             Orignial            Now
banner1_wh006      12ms                13ms
banner2_wd001      2540ms             975ms
banner3_001          5049ms            2055ms
banner4_wh001      1736ms            1076ms
banner5_001          1392ms            698ms

2009/5/13 Wei Cao <address@hidden>
thanks a lot.
Now I store the caches inside class character, it caches both the rasterizer and agg rendering result for every subshape or glyph in draw_shape_impl, Cache is invalided only when shapes is scaled or rotated.
The result is encouraging, renderering speed is much faster for some flash files, I get some flash files from, and compare execution times.
I modify the gnash code so that there is no pause between frames, so the execution time would represent rendering speed.
Flash                         Executation time
                             Orignial            Now
banner1_wh006      12ms                17ms
banner2_wd001      2540ms            1923ms
banner3_001          5049ms            3637ms
banner4_wh001      1736ms            1720ms
banner5_001          1392ms            1180ms
I also observed those flashes whose speed has no significant improvement via gprof, and found their time are cost mostly on draw_shape_mask or draw_outlines, may be caches also need implemented there.
Another finding is, even I remove all rendering operations from gnash, it's still much slower than adobe player in some cases, especially when  executing action scripts. I recompiled gnash with -O3 has little effect. Is there any way improve gnash core's efficiency ?
Wei Cao

2009/5/12 strk <address@hidden>

May be of interest to the guy that planned to contribute some
performance optimizations...


----- Forwarded message from Vinnie <address@hidden> -----

Date: Sat, 9 May 2009 13:32:25 -0700 (PDT)
From: Vinnie <address@hidden>
X-Mailer: YahooMailWebService/
Subject: [AGG] A big optimization to gradient_linear_color
Reply-To: Anti-Grain Geometry <address@hidden>
To: address@hidden
X-BeenThere: address@hidden

Based on the ideas presented in this thread, I wrote a replacement for agg::gradient_linear_color that uses a lookup table for the most expensive operation (operator[]). Its a pair of classes. One is the replacement, the other is the cache.

You will have to change the code that uses Util:Pool (my custom memory allocator):

       template<class ColorT>
       struct gradient_linear_cache
               gradient_linear_cache( Util::Pool &pool );

               struct Item
                       ColorT          c1;
                       ColorT          c2;
                       unsigned        size;
                       ColorT *        table;
                       Item *          next;

               ColorT *GetTable( const ColorT &c0, const ColorT &c1, unsigned size );

               Util::Pool &m_pool;
               Item *m_list;
               int m_count;

       template<class ColorT>
       gradient_linear_cache<ColorT>::gradient_linear_cache( Util::Pool &pool )
               :m_pool( pool )

       template<class ColorT>
               Item *item=m_list;
               while( item!=0 )
                       Item *next=item->next;
                       m_pool.Free( item->table );
                       m_pool.Free( item );

       template<class ColorT>
       ColorT *gradient_linear_cache<ColorT>::GetTable( const ColorT &c1, const ColorT &c2, unsigned size )
               ColorT *table=0;
               Item *item=m_list;
               while( item!=0 )
                       if( ::memcmp( &item->c1, &c1, sizeof(c1) )==0 &&
                               ::memcmp( &item->c2, &c2, sizeof(c2) )==0 &&
                               item->size==size )
               if( !table )
                       Item *item=(Item *)m_pool.Alloc(sizeof(*item));
                       item->table=(ColorT *)m_pool.Alloc(size*sizeof(ColorT));
                       double m=1/double(size-1);
                       for( int i=0;i<size;i++ )
                               table[i]=c1.gradient( c2, double(i) * m );
               return table;


       template<class ColorT>
   struct gradient_linear_color_fast
       typedef ColorT color_type;

               gradient_linear_color_fast( gradient_linear_cache<ColorT> &cache ):m_cache(cache) {}
       gradient_linear_color_fast( gradient_linear_cache<ColorT> &cache, const color_type& c1, const color_type& c2,
                       unsigned size = 256) :
           m_cache(cache), m_size(size)
                               m_table=m_cache.GetTable( c1, c2, size );

       unsigned size() const { return m_size; }
       color_type operator [] (unsigned v) const
           return m_table[v];

       void colors(const color_type& c1, const color_type& c2, unsigned size = 256)
                       m_table=m_cache.GetTable( c1, c2, size );
           m_size = size;

               gradient_linear_cache<ColorT> &m_cache;
               ColorT *m_table;
       unsigned m_size;

The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled.
Vector-agg-general mailing list

----- End forwarded message -----


 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign  /\  Keep it simple!

Gnash-dev mailing list

reply via email to

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