'useSWOnlyPath' was not correctly toggling between stencil and color draws so there was a mismatch with the behavior in createAlphaClipMask (i.e., we were inadvertently rendering some of the elements in a clip using SW but using stenciling for others - precisely what 'useSWOnlyPath' was intended to prevent).
Review URL: https://codereview.chromium.org/1421533007
This CL moves the allocation and storage of the GrTextContexts into the DrawingManager. The GrDrawContexts now just get their GrTextContext from the DrawingManager.
Review URL: https://codereview.chromium.org/1375153007
Adds an entry point to GrContext to allow enumeration and tracing of GPU resources
via the newly added SkTraceMemoryDump.
Plan is for Chrome to call this on each of its GrContexts.
Dumps both the total size of GPU resources, as well as the total purgeable size.
BUG=526261
Review URL: https://codereview.chromium.org/1313743002
This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
Some consequences of this are:
GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
Committed: https://skia.googlesource.com/skia/+/5b16e740fe6ab6d679083d06f07651602265081b
Review URL: https://codereview.chromium.org/1175553002
Reason for revert:
Breaking Test-Win8-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug ?
https://build.chromium.org/p/client.skia/builders/Test-Win8-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/436/steps/dm/logs/stdio
Original issue's description:
> Make GrTextContext be owned by the GrDrawContext
>
> This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
>
> Some consequences of this are:
>
> GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
>
> All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
>
> Committed: https://skia.googlesource.com/skia/+/5b16e740fe6ab6d679083d06f07651602265081bTBR=joshualitt@chromium.org,joshualitt@google.com,jvanverth@google.com,reed@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1178383003
This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
Some consequences of this are:
GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
Review URL: https://codereview.chromium.org/1175553002
This CL is ugly but it:
removes the stored SkGpuDevice back pointer from GrTextContext (at the cost of passing more parameters)
moves SkGpuDevice::internalDrawPath to GrDrawContext::drawPathFull
Unfortunately, the GrTextContext-derived classes still need the SkGpuDevice for filterTextFlags calls but I will try removing that in a separate CL.
Review URL: https://codereview.chromium.org/1157773003
This is mainly a mechanical CL. There were some fiddly bits in GrContext.cpp where it no longer had access to the GrDrawTarget (and had to use the new GrDrawContext).
I've converted GrAARectRenderer & GrOvalRenderer into static classes so I could stop allocating them.
Review URL: https://codereview.chromium.org/1151283004
This CL refactors the location of the GrBufferAllocPools so they reside entirely inside the GrBatchTarget. This is in preparation for making them use scratch resources.
Review URL: https://codereview.chromium.org/1131553002
