Improve arm (non neon) graphic performance

NEW
Unassigned

Status

()

Core
Graphics
6 years ago
6 years ago

People

(Reporter: BenWa, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.

Comment 1

6 years ago
A good start on this road could be to identify armv6 fast paths, which are currently slower than C [1], 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

Comment 2

6 years ago
(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.