This gets rid of platform-dependent hard-coded defaults, but keeps
build-time blocking if there is no GL provider (in which case layers
acceleration almost certainly won't work because it needs a GL
compositor and would likely crash without)
New prefs are
- layers.acceleration.enabled to enable HWA
- layers.acceleration.force to force it enabled (requires .enabled to be
set as well)
This is the platform part of this issue. The rest will be front-end work
(Preference UI integration and pref migration)
- Move header licensing from tri-license to MPL 2.0. MPL-compatible
other licensing has been retained where originally present.
- Remove individual superseded licensing terms.
- Remove patches, outdated readmes & incomplete patch summaries.
- Remove incomplete cairo release notes (only went up to 1.6.4 anyway).
- Rewrite COPYING to indicate the current state of the library in tree.
entire polygon.
This fixes a bug that was introduced three years ago in BZ bug 1268854.
What happened was that the final pass over the polygon assumed that the
current polygon was living in plane[0]. But due to the double buffering,
the "current" polygon alternates between plane[0] and plane[1].
The bug had also introduced an early exit so that we could hit the final
pass at a time where the current, now empty, polygon was in plane[1]. So
we would incorrectly treat all 32 points in plane[0] as part of the
final polygon.
This bug was responsible for intermittently unreasonable numbers in
CompositorOGL's fill rate / overdraw overlay.
This fixes a regression caused by the fix for CVE-2016-5252.
This fixes flickering/bars/stripes showing up during quickly-updating
operations on Intel hardware when using XRENDER.
For more information, refer to the code comment.
See #1061
Mozilla tried to enable XRENDER support with backends other than Cairo
in 286348:e13aaaaf1962 /
https://hg.mozilla.org/mozilla-central/rev/e13aaaaf1962 - at least until
they decided to completely remove XRENDER support.
The change looked innocent enough, but actually turned out to do exactly
the opposite: it forcefully enabled image offscreen surfaces with GTK2
when it was previously disabled (since
gfxPrefs::UseImageOffscreenSurfaces() will always return true) and, by
extension, disabled the XRENDER-based functionality by creating a
non-Xlib surface.
Interestingly, a previously enabled double buffering check was also
disabled by this, but since the comment for this was diverging with the
code, that behavior just sounds like yet another bug.
Instead of disabling image offscreen surfaces (at least when using the
GTK2 backend), let's force the creation of Xlib-based image surfaces
when XRENDER support is enabled. This will let UXP use the more
common/modern code paths, but also make scrolling much faster again. Too
fast scrolling may induce tearing (if not smoothed), but on the other
hand performs much better in remote computing contexts.
As an added benefit, GTK3-based builds should roughly behave the same
way. Further tests with the GTK3-backend enabled will be required in the
future.
This resolves#986.
This removes endian-based inversion of texture layout aliases when
represented as uint32. This inversion was incorrect and would cause
unknown texture formats as a result on big-endian machines (PPC64).
In theory, a convex shape transformed by an affine matrix should still
be convex. However, due to numerical imprecision of floats, when we try
to determine if something is convex, we can get different answers pre
and post a transformation (think of two line segments nearly co-linear).
Convex paths take a faster scan converter, but it is only well behaved
if the path is, in fact, convex. Thus we have to be conservative about
which paths we mark as convex, and cant's trust transformed paths to
retain their convexity. We re-calculate when a transform is applied.
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
In visual tests we see that Hamming-1 is not as good as
Lanczos-2, however it is about 40% faster, and Lanczos-2 itself is
about 30% faster than Lanczos-3. The use of Hamming-1 has been deemed
an unacceptable trade-off between quality and speed due to the limited
pixel space it operates in, so we pick Lanczos-2 here.
On modern hardware, Lanczos-2 doesn't have any noticeable impact
in normal use.
