[Pixman] performance of bilinear_interpolation

[Maksim Lin]

Thanks Siarhei and Chris for continuing to look into this.

Sorry for the delayed response, we've had to change tack and try a
different approach for our work so I've been busy on other tasks.

One thing I think I should have mentioned was that the slow rendering
problem is most evident in my sample content
(http://manichord.com/opensign/ffdebug/ffscroll.html) when it
autoscrolls the content (like a photo slideshow) which happens if
there is no user input for about 10sec after page finishes loading.
And then is most obvious when the last image is reached and it scrolls
through all the images back to the start.

Also Siarhei mentioned when the page is zoomed in firefox you get
bilinear scaling but we've got a viewport element in page to set
(maximum-scale=1) which I would have thought should always prevent any
zooming int he browser?

If you have an android device with a reasonably high res to hand and
compare the difference in performance between firefox and either
chrome or the standard android webkit-based browser, the difference is
very noticable.

With doing the cairo traces, I'm guessing that they can only be
recorded on a firefox desktop build and not on android ?

Maks.

On Wed, Oct 2, 2013 at 5:35 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Wed, Oct 02, 2013 at 04:28:00AM +0300, Siarhei Siamashka wrote:
>> On Fri, 27 Sep 2013 16:42:08 +0100
>> Chris Wilson <chris at chris-wilson.co.uk> wrote:
>>
>> > On Fri, Sep 27, 2013 at 01:17:45AM +0300, Siarhei Siamashka wrote:
>> > > Unfortunately, all that I could record so far is a broken trace :-(
>> > > Maybe somebody else will be more lucky? If anybody is interested, just
>> > > go to http://manichord.com/opensign/ffdebug/ffscroll.html in Firefox,
>> > > press ctrl-+ to zoom the page a bit and scroll it left/right for a
>> > > while. The Firefox browser needs to be launched by the cairo-trace tool.
>> >
>> > Lots of bugs in cairo-trace exposed by trying to record recent ff. :(
>> > All appear to be fixed, and I've upload a firefox-canvas-scroll.trace to
>> > the cairo-traces.git
>>
>> Thanks for the fix. Firefox traces can be recorded now. I had a
>> look at the firefox-canvas-scroll trace, but it does not fully
>> represent this interesting use case. The trace has too much of
>> blt (which eclipses the other operations), and too little of
>> bits_image_fetch_bilinear_affine_pad_x8r8g8b8.
>>
>> Profiling this trace shows:
>>
>> 33.18%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
>> 29.17%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
>> 15.86%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_fill
>>  8.63%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
>>  3.76%  cairo-perf-trac  liblzo2.so.2.0.0      [.] lzo2a_decompress
>>  1.06%  cairo-perf-trac  libc-2.15.so          [.] __memcpy_ssse3
>>
>> While running "perf record -p `pidof firefox" and profiling only the
>> scrolling part in Firefox (without any possible initial setup overhead)
>> seems to show no major blt usage:
>
> Heh, I was happy to just see the affine_pad fetcher.
>
>> 25.67%  firefox  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
>> 24.86%  firefox  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
>> 14.84%  firefox  libpixman-1.so.0.31.1 [.] sse2_fill
>>  1.87%  firefox  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
>>  0.82%  firefox  libc-2.15.so          [.] __memcpy_ssse3
>>
>>
>> I tried to record a new Firefox trace myself and also make it
>> shorter, so that it is usable on much slower embedded systems:
>>
>> https://github.com/ssvb/trimmed-cairo-traces/raw/86014d9a02d1/benchmark/t-firefox-canvas-swscroll.lzma
>>
>> 35.55%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
>> 18.83%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
>>  7.71%  cairo-perf-trac  libc-2.15.so          [.] __memset_sse2
>>  7.23%  cairo-perf-trac  liblzo2.so.2.0.0      [.] lzo2a_decompress
>>  5.01%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_fill
>>  2.71%  cairo-perf-trac  libc-2.15.so          [.] __memcpy_ssse3
>>  2.48%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
>>
>> Additionally, Firefox is configured to use client side software
>> rendering by setting gfx.xrender.enabled=false in about:config
>> (in order to make it behave more like it behaves in Android).
>
> That might have interesting effects such as the trace only using image
> constructors rather than generic surface constructors, which would need
> to be switched to make it run on any backend. The trick there though is
> trying to detect the images that are being used for pixel loading and
> avoid converting those. Fortunately the canvas is typically a fixed
> size, so it looks like we want to convert
>
> dict
>   /width 356 set
>   /height 391 set
>   /format //RGB24 set
> image
>
> to
>
>   << /width 356 /height 391 /content //COLOR >> surface
>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre