Closed Bug 749065 Opened 12 years ago Closed 8 months ago

Improve arm (non neon) graphic performance

Categories

(Core :: Graphics, defect)

x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: BenWa, Unassigned)

References

Details

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 [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
(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.
Severity: normal → S3

No longer relevant

Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.