gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] Optimization to jpeg decoding


From: strk
Subject: Re: [Gnash-dev] Optimization to jpeg decoding
Date: Thu, 27 Nov 2008 08:18:19 +0100

On Wed, Nov 26, 2008 at 08:32:03PM -0500, dolphinling wrote:
> Hitachi's animation The Hard Drive is the New Bling (Bling_Final.swf, 
> available from e.g. http://dagobah.biz/flash/Bling_Final.swf) plays slowly 
> in gnash. It contains a small number of very large jpegs (up to 3422x2516 
> px), and a profile shows that there are over 8 million calls to 
> JpegImageInput::getWidth, nearly 2% of the total cpu time (in a debug build 
> with video and audio output disabled).
> 
> All but 32 of those 8 million calls are from ImageInput::readSWFJpeg3. This 
> patch simply stores the result of getWidth within readSWFJpeg3.

The usualy way is to cache locally to the loops:

        - for (size_t i=0; i<c.size(); ++i)
        + for (size_t i=0, n=c.size(); i<n; ++i)

> This has not been run through make check--I don't have all the packages for 
> that. It has been tested on Bling_Final.swf, though, and works fine.
> 
> Jpeg decoding as a whole takes up just barely under 50% of the total time 
> (again, debug build run with -r0 so no output) so there may be other 
> improvements that could be made in the area. In fact, 
> boost::scoped_array<unsigned char>::operator[] is called nearly 25 million 
> times from readSWFJpeg3, for 5.67% of the run time, but I don't see a 
> trivial way to eliminate those calls like with getWidth.

I tought that operator would be inlined ? Are you building with inlines
turned off by any chance ? Anyway you can get rid of that call by
assigning the base to an unsigned char* and doing pointer math later
on:

        unsigned char* ptr = myScopedArray.get();
        - myScopedArray[50] ...
        + *(ptr+50)

Could be incrementally advancing 'ptr' would also save some time.

> Any comments or questions of course welcome.

Check memory allocations, could kill performance w/out profilers
noticing much. Like, see how allocs/deallocs can be reduced.

--strk;




reply via email to

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