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 http://www.bannerserver.com/, 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 <cyg....@gmail.com> > 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 <s...@keybit.net> > > May be of interest to the guy that planned to contribute some >> performance optimizations... >> >> --strk; >> >> ----- Forwarded message from Vinnie <thev...@yahoo.com> ----- >> >> Date: Sat, 9 May 2009 13:32:25 -0700 (PDT) >> From: Vinnie <thev...@yahoo.com> >> X-Mailer: YahooMailWebService/0.7.289.1 >> Subject: [AGG] A big optimization to gradient_linear_color >> Reply-To: Anti-Grain Geometry <vector-agg-gene...@lists.sourceforge.net> >> To: vector-agg-gene...@lists.sourceforge.net >> X-Spam-Level: >> X-BeenThere: vector-agg-gene...@lists.sourceforge.net >> >> >> 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 >> vector-agg-gene...@lists.sourceforge.net >> 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 >> Gnash-dev@gnu.org >> http://lists.gnu.org/mailman/listinfo/gnash-dev >> > >
_______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
