This is an approach to antialiased concave path rendering
on the GPU without using MSAA. It uses GrTessellator to
extract boundary contours from the given path, then
inflates by half a pixel in screen space each direction,
then renders the result with zero alpha on the outer
contour and one alpha on in the inner contour. This
requires two passes through the tessellation code: one
to extract the boundaries, then one to tessellate the
result.
This gives approximately a 3X improvement on the IE
chalkboard demo in non-MSAA mode, a 30-40% improvement
on MotionMark's "Fill Paths", and a ~3X improvement on
MotionMark's "canvas arcTo segments".
It works best for large, simple paths, so there's currently
a limit of 10 verbs in the onCanDrawPath() check. This
dovetails nicely with the distance field path renderer's
support for small, detailed (and cached) paths.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
NOTRY=true
Review-Url: https://codereview.chromium.org/1152733009
When we have a general layout, we need to always add a barrier even if
leaving the layout in general since we don't know what the use case for
general was with the old layout.
This doesn't seem to fix any of our synchronization issues which makes
sense since we don't really use a general layout much. The only place it
is used is for mipmap generation, but then we add explicit barriers in
that function itself and the first use of the image after mipmap generation
will change the layout to something other than general, usually SHADER_READ.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2298483002
Review-Url: https://codereview.chromium.org/2298483002
Reason for revert:
Causing asserts in GLPrograms test on Mac.
Original issue's description:
> Screenspace AA tessellated GPU path rendering.
>
> This is an approach to antialiased concave path rendering
> on the GPU without using MSAA. It uses GrTessellator to
> extract boundary contours from the given path, then
> inflates by half a pixel in screen space each direction,
> then renders the result with zero alpha on the outer
> contour and one alpha on in the inner contour. This
> requires two passes through the tessellation code: one
> to extract the boundaries, then one to tessellate the
> result.
>
> This gives approximately a 3X improvement on the IE
> chalkboard demo in non-MSAA mode, a 30-40% improvement
> on MotionMark's "Fill Paths", and a ~3X improvement on
> MotionMark's "canvas arcTo segments".
>
> It works best for large, simple paths, so there's currently
> a limit of 10 verbs in the onCanDrawPath() check. This
> dovetails nicely with the distance field path renderer's
> support for small, detailed (and cached) paths.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
>
> Committed: https://skia.googlesource.com/skia/+/9992bdef8ae97b3e5b109d278ccfab84c66bcbf0TBR=bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2299683002
This is an approach to antialiased concave path rendering
on the GPU without using MSAA. It uses GrTessellator to
extract boundary contours from the given path, then
inflates by half a pixel in screen space each direction,
then renders the result with zero alpha on the outer
contour and one alpha on in the inner contour. This
requires two passes through the tessellation code: one
to extract the boundaries, then one to tessellate the
result.
This gives approximately a 3X improvement on the IE
chalkboard demo in non-MSAA mode, a 30-40% improvement
on MotionMark's "Fill Paths", and a ~3X improvement on
MotionMark's "canvas arcTo segments".
It works best for large, simple paths, so there's currently
a limit of 10 verbs in the onCanDrawPath() check. This
dovetails nicely with the distance field path renderer's
support for small, detailed (and cached) paths.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
Review-Url: https://codereview.chromium.org/1152733009
This allows us to do copies from:
msaa->msaa with same sample count
msaa->no-msaa with a resolve
Still missing support for no-msaa to msaa which will require a copyAsDraw
which is currently stalled and fixing possible driver bugs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2294533002
Review-Url: https://codereview.chromium.org/2294533002
Also make sources_when_disabled and public_defines optional arguments.
These are the two mechanisms code uses to turn itself off...
probably at most one is ever used per optional.
Update fiddle to not crash when there's no PDF backend.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292343003
Review-Url: https://codereview.chromium.org/2292343003
This fixes this warning-as-error, so we don't have to stifle it any more:
error: 'register' storage class specifier is deprecated and incompatible with C++1z [-Werror,-Wdeprecated-register]
Tested by building for mipsel via GN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2289293002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2289293002
- Switch to portable typeface, to avoid per-platform diffs in the labels
- Stretch out the image slightly, to avoid overlap with larger font
- Fix several tests that were no longer matching ground-truth. We treat
SkColor as sRGB, so 0x7F is incorrect, for example. Several of the
XferMode tests had similar math errors now. Computed new values, and
verified that they work as expected.
- Removed a couple tests that were mixing color and alpha in funny ways
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2288053003
Review-Url: https://codereview.chromium.org/2288053003
Verify the rules that we're converging on for surfaces:
- For 8888, we only support sRGB-like gamma, or no color space at all.
- For F16, we require a color space, with linear gamma.
- For all other formats, we do not support color spaces.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270823002
Review-Url: https://codereview.chromium.org/2270823002
Using the spinlock is only necessary when we multiple threads
might use a GrContext. Android uses the GrContext from a
single thread, so these locks are not needed.
This is a temporary fix until we can refactor to avoid
creating GrContexts in a global memory pool.
BUG=skia:5696
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293633003
Review-Url: https://codereview.chromium.org/2293633003
We don't need to syncronize the mapped memory writes to the buffer since
all CPU writes are already syncronized when we submit a command buffer. And we are using coherent memory for buffers so we don't need to call vkFlushMappedMemory
BUG=skia:
Review-Url: https://codereview.chromium.org/2289973002
This ought to support compiles for now.
Am I picking up my CIPD ndk packages right?
The main thing to note is that I'm passing the target_arch directly through
as target_cpu. This means these bots will have a slightly different naming
convention than we've been using, but it'll agree with what you must type
yourself when using GN to build for Android:
- Arm7 -> arm
- Arm64 -> arm64
- Mips -> mipsel
- Mips64 -> mips64el
- x86 -> x86 (unchanged)
- x86_64 -> x64
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292663002
Review-Url: https://codereview.chromium.org/2292663002
