| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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 reverts commit 09a8b2f19689b679b1268a3004ec5e3f37b9732a.
|
|
|
|
|
|
| |
entire polygon.
This fixes a regression caused by the fix for CVE-2016-5252
|
| |
|
|
|
| |
Fallout from 227b23606b0401245c9f0b15effd45b876b90260
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
can be null because of OOM or gfx device reset. r=dvander
MozReview-Commit-ID: HX2qsWLZpMg
--HG--
extra : rebase_source : 046befc11151461a682842c31e2ce39247a5e1d8
|
|
|
|
| |
Resolves #20
|
|
|
|
| |
Tag #20
|
|
|
|
| |
Issue #186
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Upstream port of commit 7469a9341afab19271b8ef07af5c16a0f2c4ccc1
|
|
|
|
| |
Upstream port.
|
|
|
|
|
|
| |
This reverts commit 260b06c1c96285459947231a93f08e413be89dd0.
This fixes #976
|
| |
|
| |
|
| |
|
|
|
|
| |
This resolves #881
|
|
|
|
|
|
| |
Backport of:
https://skia.googlesource.com/skia/+/1e259cda4fb7f12e98dd611bd651f40ebef2d14a
https://skia.googlesource.com/skia/+/73be50da2a1fe8944f2623a511fda1957eed708a
|
|
|
|
|
|
| |
Backport of:
https://skia.googlesource.com/skia/+/c3d8a48f1b27370049aa512019cd726c59354743
https://skia.googlesource.com/skia/+/8051d38358293df1e5b8a1a513f8114147ec9fa3
|
|
|
|
| |
Tag #21.
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
This reverts commit e7189e33f533f9b974b22c2110b522a13bc4c7f6.
|
| |
|
| |
|
|
|
|
| |
This resolves #668
|
|
|
|
| |
This resolves #626
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
compatible with the worker shutdown status
|
| |
|
|
|
|
| |
transform function uses the grid size. r=Bas a=jcristau
|
| |
|
| |
|
| |
|
| |
|