summaryrefslogtreecommitdiff
path: root/gfx/2d
Commit message (Collapse)AuthorAge
* Correctly return zero vertices if clipping plane 0 or 2 clip away theMarkus Stange2019-09-04
| | | | | | | | | | | | | | | | | | 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.
* Revert "Correctly return zero vertices if clipping plane 0 or 2 clip away the"wolfbeast2019-09-04
| | | | This reverts commit 09a8b2f19689b679b1268a3004ec5e3f37b9732a.
* Correctly return zero vertices if clipping plane 0 or 2 clip away thewolfbeast2019-09-01
| | | | | | entire polygon. This fixes a regression caused by the fix for CVE-2016-5252
* Bug 1360343 - ensure maskSurface is not null before dereference, since it ↵cku2019-04-03
| | | | | | | | | can be null because of OOM or gfx device reset. r=dvander MozReview-Commit-ID: HX2qsWLZpMg --HG-- extra : rebase_source : 046befc11151461a682842c31e2ce39247a5e1d8
* Remove texture layout endian-ness check for Moz2D.wolfbeast2019-03-05
| | | | | | | | 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).
* Switch to Lanczos scaling from Hamming to get acceptable fast downscaling.wolfbeast2018-07-14
| | | | | | | | | | 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.
* Improve the SSSE3 scaler.wolfbeast2018-06-07
|
* Bug 1393367 - Change MOZ_ASSERT to MOZ_RELEASE_ASSERT. r=mstange, r=fbraun, ↵Miko Mynttinen2018-04-19
| | | | | | | | a=RyanVM --HG-- extra : source : 1908cd8ed88dd4f77a99dff39c193d7d3f435195 extra : intermediate-source : 9718d92fab4d9a39acdc2afb0302b6fcd7997f6c
* Add m-esr52 at 52.6.0Matt A. Tobin2018-02-02