This fixes a crash we saw when we switch vulkan copies as draws to creating
their own secondary command buffer. The crash came from the perf blendmode
tests when using an advanced blend mode. They would do 1000 draws which forced
us into creating 2000 command buffers (since the dst copies and the normal draws
each used them). I tested without the copies as draws change and just increasing
the total number of draws we do and was able to repro the crash.
Besides fixing the above OOM crash, I am also seeing a 5-10% perf gain on the
blendmode micro benches which is nice
Bug: skia:
Change-Id: I9266ea0ba02a755f54dabd4ee804963ab0c9b684
Reviewed-on: https://skia-review.googlesource.com/c/175436
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Uninstantiated: a state of not being instantiated.
Deinstantiate: transition from instantiated to uninstantiated state.
Change-Id: Id7b6b295267674a9915f95105d73fabfcc3555de
Reviewed-on: https://skia-review.googlesource.com/c/175586
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:
Change-Id: I365c82a058c97e8741ee91e999cb6faab5a5ecf5
Reviewed-on: https://skia-review.googlesource.com/c/175422
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Follow-ups assuming this sticks:
- remove client overrides, so we can remove the (empty) base class virtuals
- mark as obsolete the .skp enums for these entrypoints, and note date
- remove glyphrunlist helpers that now may not have any callers
- remove DrawCommands related to these entrypoints
Bug: skia:
Change-Id: I44b4e6ef3bee61911e77b9b2ab73f82c0817536a
Reviewed-on: https://skia-review.googlesource.com/c/175240
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Bug: skia:
Change-Id: I9269288bbb861cd02efa7b5dfe2c9434ec39064e
Reviewed-on: https://skia-review.googlesource.com/c/174309
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit 10273c1d5f.
Reason for revert: bad gms
Original change's description:
> Use unnormalized coords all the way through with GL_TEXTURE_RECTANGLE textures.
>
> We used to unnormalize them in the shader via SkSL.
>
> This allows us to support GL_TEXTURE_RECTANGLE without having textureSize()
> available in GLSL.
>
> Change-Id: Ibe63a302228811933ef000251db4cad9aaf4f2ea
> Reviewed-on: https://skia-review.googlesource.com/c/174068
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,brianosman@google.com
Change-Id: I9bf38e1040578becba28ac8cccd81e2af2844278
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/175252
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:7903
Change-Id: I69b65fc1cfcc2cc5045bb3b75395f9a256ade278
Reviewed-on: https://skia-review.googlesource.com/c/172979
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Read only textures and proxies fail writePixels, as copy dsts, and mip
regeneration.
Bug: skia:8509
Change-Id: Iaa0b473cc9a9930fde3ef0e91373d5040650de35
Reviewed-on: https://skia-review.googlesource.com/c/174316
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
We used to unnormalize them in the shader via SkSL.
This allows us to support GL_TEXTURE_RECTANGLE without having textureSize()
available in GLSL.
Change-Id: Ibe63a302228811933ef000251db4cad9aaf4f2ea
Reviewed-on: https://skia-review.googlesource.com/c/174068
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:8579
Zero-initialize the pixel buffer that wuffs uses inside the frame rect.
If the encoded image is incomplete, we will swizzle this memory into the
destination, so this prevents swizzling uninitialized memory.
In addition, zero-initialize the client's memory if the above buffer
will not fill it, and if the frame is independent.
Move decodeFrameConfig into onStartIncrementalDecode. This makes it
clear that we haven't begun decoding the pixels so rowsDecoded is
irrelevant. Update the documentation for onStartIncrementalDecode to
make it clear that it can be called more than once (and when to do so).
If a frame is incomplete and depends on prior frames, do not blend it.
This will overwrite pixels from the prior frames without a way to undo.
Current clients only want to show incomplete images for the first frame
anyway.
Add some debugging information to Codec_partialAnim test, including
writing out pngs when failing the test.
TBR=djsollen@google.com for documentation change in SkCodec.h
Change-Id: I85c8ca4075301306f4738ddfc2f5992a5745108b
Reviewed-on: https://skia-review.googlesource.com/c/174310
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Nigel Tao <nigeltao@google.com>
Change-Id: I4960b1cd055daf44637e95825f82cb7fe2ce134a
Reviewed-on: https://skia-review.googlesource.com/c/174285
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I11ff57dca2c48519bc3a23e36da01bf40d1b329c
Reviewed-on: https://skia-review.googlesource.com/c/174221
Commit-Queue: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:8410 chromium:876349
Change-Id: Ib97c82cd165f7e2f2e94c65fc307220b99053df3
Reviewed-on: https://skia-review.googlesource.com/c/174065
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: I04b6cbfe083c32a25205e04a4b15672d4b678a9c
Reviewed-on: https://skia-review.googlesource.com/c/174063
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
In theory, a convex shape is still convex if transformed by an affine
matrix. However, SkPath segments are specified using floats, and attributes
like collinearity can break under some transforms due to finite precision.
Computing convexity is non-trivial, so there is value in SkPath caching this
calculation. Convexity is useful, as both the CPU and GPU backends can draw
convex shapes faster than non-convex.
To balance these two (fragile float math and value of caching convexity),
this CL invalidates this cached state if the transform could change convexity.
In the general case, it is assumed that convexity could change. Special cases
where it is safe to keep the cached state after transform are:
- identity transform
- scale/translate transform if the path is known to be axis-aligned
All other combinations invalidate the cached state, forcing it to be
recomputed.
"axis-aligned" means the segments in the path are all axis-aligned, horizontal
or vertical (e.g. a rect or rrect)
Bug: 899689
Change-Id: I1381273eaff61d6b7134ae94b4f251c69991081a
Reviewed-on: https://skia-review.googlesource.com/c/173226
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
This reverts commit 26d8d77aae.
Reason for revert: speculative, in case this is blocking the chrome roll
Original change's description:
> don't trust convexity with affine transforms
>
> In theory, a convex shape transformed by an affine matrix should still
> be convex. However, due to numerical nastiness 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 colinear).
>
> 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.
>
> This bug found a case where a "convex" path, after going through a transform,
> became (according to our measure) non-convex. The bug was that we *thought*
> that once convex always convex, but in reality it was not. The fix (hack) is
> to notice when we transform by an affine matrix (we're still assuming/hoping
> that scaling and translate keep things convex (1)...) and mark the convexity
> as "unknown", forcing us to re-compute it.
>
> This will slow down these paths, since it costs something to compute convexity.
> Hopefully non-scale-translate transforms are rare, so we won't notice the
> speed loss too much.
>
> (1) This is not proven. If we find scaling/translation to break our notion of
> convexity, we'll need to get more aggressive/clever to find a fix.
>
>
> Bug: 899689
> Change-Id: I5921eca247428bf89380bc2395fe373fa70deb1d
> Reviewed-on: https://skia-review.googlesource.com/c/173080
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Cary Clark <caryclark@google.com>
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
TBR=mtklein@google.com,jvanverth@google.com,caryclark@google.com,reed@google.com,caryclark@skia.org
Change-Id: I5d846798f2c34c6576591a3c3125cfdc3c72dbdc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 899689
Reviewed-on: https://skia-review.googlesource.com/c/173162
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
In theory, a convex shape transformed by an affine matrix should still
be convex. However, due to numerical nastiness 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 colinear).
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.
This bug found a case where a "convex" path, after going through a transform,
became (according to our measure) non-convex. The bug was that we *thought*
that once convex always convex, but in reality it was not. The fix (hack) is
to notice when we transform by an affine matrix (we're still assuming/hoping
that scaling and translate keep things convex (1)...) and mark the convexity
as "unknown", forcing us to re-compute it.
This will slow down these paths, since it costs something to compute convexity.
Hopefully non-scale-translate transforms are rare, so we won't notice the
speed loss too much.
(1) This is not proven. If we find scaling/translation to break our notion of
convexity, we'll need to get more aggressive/clever to find a fix.
Bug: 899689
Change-Id: I5921eca247428bf89380bc2395fe373fa70deb1d
Reviewed-on: https://skia-review.googlesource.com/c/173080
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This should allow clients to include Skia and their vulkan files in any
order. However, it does require that when clients are building their
files that include skia with vulkan, they must have vulkan/vulkan_core.h
on their include path somewhere.
Bug: skia:
Change-Id: I969db396c92127be7c8df754926d175f38b8aafa
Reviewed-on: https://skia-review.googlesource.com/c/172147
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Change-Id: I900a661f346a10dbd8002bfe383d1705138feb50
Reviewed-on: https://skia-review.googlesource.com/c/146401
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Bug: skia:
Change-Id: Ibd636b9e1bf932033c3161c862523f841cb85e79
Reviewed-on: https://skia-review.googlesource.com/c/171005
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
GrRenderTargetOpList maintains an array of op chains. When it receives a
new op it tries to add it to an existing chain, working backwards from
the end of the current array. If the op can be added to a chain it
additionally tries to merge the new op with ops already in the chain
before adding it to the tail of the chain.
In forward combining it tries to concatenate chains. If chains can
concatenate it also attempts to merge ops between the two chains.
Now op chaining results reported by Op subclasses must be transitive.
Moreover, if op A is able to merge with B then it must be the case that
any op that can chain with A will either merge or chain with any op that
can chain to B.
Bug: skia:8491
Change-Id: Ib6a2a669acd4257134a37d271289b8b3f247cd3f
Reviewed-on: https://skia-review.googlesource.com/c/170351
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Adds setVertexAttributes and setInstanceAttributes. These take a pointer
to the first attribute, and a count. The count is the total number of
possible attributes, though some may not be initialized. The base class
computes the number of initialized attributes, pre-computes the strides,
and only allows subsequent access to the initialized attributes.
The attributes need to be allocated contiguously. Some GPs place them in
an array, though most just place them as consecutive members, and pass
a pointer to the first one.
Indexed access would be possible, but now it makes more sense to iterate
over all attributes, so enable that, and use range-based for everywhere.
Completely remove the per-attribute offset helper (again - possible, but
not real helpful), and make the stride always available. In many ops,
just use the GP's computed stride, rather than re-computing it.
Bug: skia:
Change-Id: Ie4cccb7969a98ee5a10b373e714fbd702e875b3e
Reviewed-on: https://skia-review.googlesource.com/c/169241
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
edging settings are needed for metrics calls, as well as drawing, hence
we really have to include them in almost every SkFont call/usage, so I
guess we can just accept them as real.
This seems to imply that we have to document what happens in drawTextBlob,
since it has a bunch of SkFonts (runs) AND a paint. This is the situation
today of course, and I had hoped to simplify it, but I think I've failed.
Proposal dox for drawTextBlob.
drawTextBlob respects the paint when drawing the blog, but it IGNORES the
paint's antialias (and lcdrender) flags, as these are already specified in
the blob's runs.
Bug: skia:2664, skia:8494
Change-Id: I8f69186c9c337d98d058919f53b7901ff830a16e
Reviewed-on: https://skia-review.googlesource.com/c/170352
Auto-Submit: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
It *seems* that chrome only ever uses glyphs, so I hope we can skip the encoding parameter.
Bug: skia:
Change-Id: I3b6857ba6a37050a9fd0913a16b980bc45d54bda
Reviewed-on: https://skia-review.googlesource.com/c/170341
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
