HI Siarhei, Thanks for taking a look at this. I'm away on leave so I didn't get a chance to reply to Søren earlier and say thanks to him having a look too.
The thing is though, I see the poor performance for this webpage happening when we are displaying this on a 1920x1080 monitor (hence the size of the images in that slideshow) and it seems the content fits the screen (we customised android to make firefox be fullscreen with no chrome) but perhaps we've done something wrong there and firefox is zooming the content so I'll follow that up straight away to double check. Though because the firefox profiler add-on doesnt support native stack traces I can't be sure the on x86 we are seeing exactly the same slow-path issue as when profiling with arm devies. On a couple of arm devices (Nexus10 and a Amlogic AML8726-M based tablet) where I can get full traces from the firefox profiler add-on I do see which pixman functions are being called and see the slow path being use a lot of the time. Now here is the strange thing: on another Arm tablet, a Allwinner A10 based one (same res 1024x768 as the Amlogic tablet) I *dont* see the slow path being taken, the Neon based function are always called. The rendering performance is still visually not that great on the A10 tablet, but it is roughly the same as for the webkit based default browser, which on all the other devices is drastically better then firefox. I haven't come across how to do cairo traces, would these work on x86 based android devices when running firefox? If so I'd be very happy to run them and see if I can find more useful information, would you be able to point me to some instructions on how to run them? thanks again, Maks. On Thu, Sep 26, 2013 at 9:20 AM, Siarhei Siamashka <[email protected]> wrote: > On Wed, 11 Sep 2013 17:07:52 +1000 > Maksim Lin <[email protected]> wrote: > >> Hi, >> >> I'm working on finding out the cause of poor drawing performance of >> Firefox on android: >> https://bugzilla.mozilla.org/show_bug.cgi?id=911882 >> >> The html causing the problem is essentially doing a image translation: >> http://manichord.com/opensign/ffdebug/ffscroll.html > > When this web page is zoomed in Firefox, we get bilinear scaling for > x8r8g8b8 -> a8r8g8b8 (SRC operator, PAD repeat). And there is simply no > NEON or SSE2 optimized fast path in the currently released versions of > pixman (or in the Mozilla's internal pixman copy), which could do this > scaling while also setting the alpha channel to 0xFF at the same time. > > A universal general solution would be to extend the SSSE3 bilinear > fetch iterator in pixman git repository to handle all repeat types > and also add NEON and SSE2 bilinear fetch iterators. > > But first it would be a good idea to record a cairo trace for this > use case. > > -- > Best regards, > Siarhei Siamashka _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
