gnash-dev
[Top][All Lists]
Advanced

[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, 13 May 2009 18:45:52 +0800

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 http://www.bannerserver.com/, 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 ?
 
 
Regards,
 
 
Wei Cao


 
2009/5/12 strk <address@hidden>
May be of interest to the guy that planned to contribute some
performance optimizations...

--strk;

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

Date: Sat, 9 May 2009 13:32:25 -0700 (PDT)
From: Vinnie <address@hidden>
X-Mailer: YahooMailWebService/0.7.289.1
Subject: [AGG] A big optimization to gradient_linear_color
Reply-To: Anti-Grain Geometry <address@hidden>
To: address@hidden
X-Spam-Level:
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 );
               ~gradient_linear_cache();

               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 )
       {
               m_list=0;
               m_count=0;
       }

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

       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 )
                       {
                               table=item->table;
                               break;
                       }
                       item=item->next;
               }
               if( !table )
               {
                       Item *item=(Item *)m_pool.Alloc(sizeof(*item));
                       item->table=(ColorT *)m_pool.Alloc(size*sizeof(ColorT));
                       item->next=m_list;
                       item->c1=c1;
                       item->c2=c2;
                       item->size=size;
                       m_list=item;
                       table=item->table;
                       double m=1/double(size-1);
                       for( int i=0;i<size;i++ )
                               table[i]=c1.gradient( c2, double(i) * m );
                       m_count++;
               }
               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. http://p.sf.net/sfu/kodak-com
_______________________________________________
Vector-agg-general mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

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

--

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!


_______________________________________________
Gnash-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnash-dev


reply via email to

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