When we ship to tablets we will need to profile and optimize slow non neon path (tegra v2 devices). I left this tittle to be general because we'll have to decide if the best bet is pixman improvements or using skia.
A good start on this road could be to identify armv6 fast paths, which are currently slower than C , and then either improve them or drop. There is no need to penalise non-neon hardware unnecessarily. 1. http://lists.freedesktop.org/archives/pixman/2011-July/001339.html
(In reply to Benoit Girard (:BenWa) from comment #0) > I left this tittle to be general because we'll have to decide > if the best bet is pixman improvements or using skia. Regarding "pixman improvements" bet, here is the list of Mozilla contributions to pixman for a few last years, and most of the relatively recent ones are just tiny tweaks: http://cgit.freedesktop.org/pixman/log/?qt=author&q=mozilla There is not much Mozilla presence in pixman bugtracker either: https://bugs.freedesktop.org/buglist.cgi?bug_status=__all__&list_id=69331&product=pixman&query_format=specific&order=bug_id%20DESC&query_based_on= To me it looks like the decision had been made years ago. And there is some obvious logic in it: using Skia as a backend allows Mozilla to be at least as good (or as bad) as Chrome. Maybe Mozilla does not have any resources to even try treating pixman as a backup solution? Still this is regrettable, because there are a lot of low hanging fruits for armv6 and x86 optimizations in pixman.
You need to log in before you can comment on or make changes to this bug.