Brings in the following functionality:
ARB_draw_instanced
ARB_instanced_arrays
NV_bindless_texture
EXT_direct_state_access
KHR_debug
Also cleans up some of the NVPR extension loading.
BUG=skia:
Review URL: https://codereview.chromium.org/1185573003
Adds a new FBO type kStencil_MSFBOType that is selected whenever
NV_framebuffer_mixed_samples extension is available. In this new
FBO type a non-msaa color buffer is created with a multisampled
stencil buffer attachment.
Replaces numSamples() with separate numColorSamples and numStencilSamples
methods in RenderTarget.
In mixed samples mode non-MSAA codepaths are used to draw simple shapes,
while NVPR-rendered paths and text are rendered with a multisampled
stencil.
BUG=skia:3177
Review URL: https://codereview.chromium.org/1001503002
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
Tweak some test values to pass with floats.
As expected, this regresses matrix44_setconcat_general by about 2x.
BUG=skia:
Review URL: https://codereview.chromium.org/1169813006
Moves the coverage logic into GrGLXferProcessor for XPs that perform
dst reads. XPs that don't use a dst read are still responsible to
handle coverage on their own.
BUG=skia:
Review URL: https://codereview.chromium.org/1170553002
Reason for revert:
Blink
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
>
> Committed: https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1156583004
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
Review URL: https://codereview.chromium.org/1152553006
Long lived SkImageHeap objects currently accumulate refs indefinitely.
This leads to massive memory leaks in the gpu-accelerated 2D canvas
code path. This CL does not implement a general fix for SkGPipe, but
it resolves the leak in SkDeferredCanvas (currently the only user
of SkGPipe) by resetting the image heap when the deferral queue is
flushed. This change also fixes the accounting of bytes allocated
by referenced images in order to trigger flushing heuristics
appropriately.
BUG=crbug.com/494148
Review URL: https://codereview.chromium.org/1145893007
Reason for revert:
breaking tests
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4eTBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1143083006
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Review URL: https://codereview.chromium.org/1152553006
Renames getInvariantOutput to getInvariantBlendedColor on GrXPFactory
and redefines it to not account for coverage conflation. This is the
information that all the callsites actually wanted to know.
BUG=skia:
Review URL: https://codereview.chromium.org/1161273005
Reason for revert:
gfx_unittests (under linux_asan)
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Direct leak of 368 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f7060ebdf in _cairo_image_surface_create_for_pixman_image /build/buildd/cairo-1.10.2/src/cairo-image-surface.c:158@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Indirect leak of 256 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f6c7be26a in _pixman_image_allocate /build/buildd/pixman-0.30.2/build/pixman/../../pixman/pixman-image.c:184@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
I think they are creating a cairo surface, but it has no pixels (zero size?). In this CL, if I see no pixels, I ignore the call-back which is used to free the surface (doh).
Original issue's description:
> Revert[4] of add asserts around results from requestLock
>
> This reverts commit 19663e54c0.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/df91b73a34e3a306c93a5e320704736255c3d9f0TBR=reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1151063005
Reason for revert:
asserts in ui/gfx unittests (need to investigate why)
[ RUN ] RenderTextTest.SelectionKeepsLigatures
[14602:14602:0529/134016:16779526944:INFO:SkPixelRef.cpp(164)] ../../third_party/skia/src/core/SkPixelRef.cpp:164: failed assertion "pixels"
Original issue's description:
> add asserts around results from requestLock and lockPixels, ensuring that true always means we have non-null pixels (and non-null colortable if that matches the colortype)
>
> BUG= 491975
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/f941a68126d8fe647eaea902c244c466568b7809TBR=scroggo@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 491975
Review URL: https://codereview.chromium.org/1159013006
