Also, move first-direction into SkPathRef.h so it can be referenced
by name in SkPath (instead of using uint8_t)
No functional change expected.
Change-Id: Ica4a8357a8156fd9a516118f23599a965b0fdd47
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313980
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
For some strange reason, bit 15 seems to create problems on iphone6
for gles. This works fine for mtl. Shift down to bits 13 and 14.
Change-Id: Id8e39d46bf23decaf1bd1a6058dd3fc999fc31cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313907
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This flag was added recently since I noticed it was missing and should
be checked. However, Dawn fails this check in chrome since it doesn't
report this flag correctly to DDLs. Going back to the previous status
quo for now.
Bug: skia:10672
Change-Id: Ib825fe5a69bff7af0d9893b95cd4df80289be7b2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313905
Commit-Queue: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Add API to atlas locator to manipulate the PlotLocator and rect.
The next step is to store the page index in the rect using the
update methods to maintain the invariants between the PlotLocator
and the rect.
Change-Id: I7e27d20ffce7f08f71fef35d02bbd59eb4235dae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313903
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Store the 2 page index bits in bits 14 and 15 of U. This allows
several simplifications.
Change-Id: Ib3ce98f0f5a430849acc0e6f6f3ecfabdb3f038d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313896
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Subsequent CLs can work on combining convexity and direction
Bug: skia:10670
Change-Id: Ia44769ea88ffd99a56d4c6729a80a2044e790ec2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313837
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This was only used by a single visitor (MergeSampleUsageVisitor) and
just for its context. It is simpler for MergeSampleUsageVisitor to just
hold onto a Context& directly.
Change-Id: Ia38e3fa1b67498ac4c65a6a8450ca87aea1e0963
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313876
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This sample attempts to re-create an image's alpha channel by drawing it
one pixel at a time and timing how long each pixel takes to draw.
The "abc" text should appear twice normally, and the third and fourth
versions are reconstructed from timing, one by timing 1:1 pixel draws,
the other by timing 1x1:1024x1024 upscale into an offscreen. It's not
meant to be an exact reconstruction, but you can easily see the shapes,
particularly at -O0, -O1, and -Os. Auto-vectorization from -O2/-O3 do
a good amount to cover up the problem.
The legacy CPU backend is the main place to look. I haven't been able
to reconstruct any images using SkRasterPipelineBlitter or SkVMBlitter,
and while on the GPU I do see non-random patterns in the timing, it
appears to be the same single pattern across devices, OSes, GPUs, GPU
APIs and content... I assume it's something like our resource caching
policy.
This can't really be a GM, given how it draws non-deterministically.
Bug: chromium:1088224
Change-Id: I2ec79c8dd407ecb104fd9bf0c8039cb6dd1fe436
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313466
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This doesn't change any behavior, just moves out repeated code to a
common place, and adds a handful of comments.
The code which creates a block of inlined statements has also been
reorganized a bit; the unique_ptr<Block> of inlined statements is now
created earlier, instead of creating a vector of statements and then
wrapping it in a Block in two separate places. Again, this shouldn't
cause any externally-visible behavioral changes; it's just doing the
same steps in a different order.
Change-Id: I89e87d93cf505ee30a49917390afab6a4f226aeb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313839
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
SkBlitRow_opts.h is including this and masking the issue.
Change-Id: I0a5f873a2f9c486d40f86e79c8119081495ae1ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313810
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This has always been a potential source of a bug. If the same texture is
used twice in a shader with different swizzles we would overwrite the
swizzle for the first use by that of the second use since there is
only one fixed function swizzle per texture. It's not part of the
sampler state.
We set the swizzle when it is a feature, but always to RGBA.
Also, highly speculative that this may improve ANGLE D3D11 ES3
performance compared to ES2.
Bug: skia:10644
Change-Id: I8877afc3043c5ddaafd26ea9f9bd372303328c71
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313682
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Using Chromium's clang with skia_use_metal=true produces
../src/gpu/mtl/GrMtlCommandBuffer.h:25:5: warning: '~GrMtlCommandBuffer' overrides a destructor but is not marked 'override' [-Wsuggest-destructor-override]
~GrMtlCommandBuffer();
Change-Id: I177a6645a37cf9853b9284798eb48997428e1854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313808
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I9b908bc1cdd28f3bd6819096420b1d119eecd62e
Bug: skia:10669
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313836
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Joe Gregorio <jcgregorio@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
In a follow-up, I will explore more clearly tying together convexity
and direction internally -- perhaps a unified enum?
[ unknown, convex_cw, convex_ccw, concave ]
Change-Id: I9fc2a2205f40050f4c24c5bec7fc25c8b6d2461c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313680
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Force ES2 level shading language on ANGLE.
Will be reverted. Only affects Skia tool builds.
Bug: skia:10644
Change-Id: Ic52d6afae7f784b173725a9353d5f43f2da3ca72
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313703
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This is an experiment to gauge the additional cost of an extra
indirection. I plan to put it into production to see the impact in
the different clients. The long term goal is to have an API that
works on dense glyph indexes instead of SkGlyph*. This moves from a
system with multiple hash lookups to a single cache lookup. The
lookup would happen on the Renderer side, and the index could be
used to find the glyph directly instead of using a hash map with the
packed glyph id on the GPU side. Eventually, the extra indirection
cost would be recouped by small glyph data (an int instead of a
pointer), and fewer hashmap lookups.
Change-Id: I6dcad6253de54df13c000ecc936a99028cbff5a7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313681
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This should fix the current bot failures from previous change.
Change-Id: I1ef4736e9318de6797445a5964c5d29f186811ed
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313704
Commit-Queue: Greg Daniel <egdaniel@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Greg Daniel <egdaniel@google.com>
Reviewed-by: Herb Derby <herb@google.com>
It has been replaced by ProgramVisitors.
Change-Id: I3a79dd46b191d82b025d515c9810e9593f7cf909
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313684
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
There doesn't seem to be any reason to use a raw pointer for the
IRGenerator.
Change-Id: I5a37ff8ee212534dc8357722aaf70637623840bb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313720
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This also includes all the plumbing of this flag throughout our proxy
and surface system.
Bug: skia:10409
Change-Id: I48d40012049240cfa80e045ea090f68ce2d2ff0d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313676
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
These ProgramVisitor classes do the exact same work as count_returns.
Hopefully they are easier for us to reason about, since we no longer
have one omni-method trying to implement three different counts at once.
count_returns still exists in this CL so we can SkASSERT that our
results are unchanged. It is removed entirely in the followup CL.
Change-Id: I17588bcec375a946da6cc6fdb5bab9a3d7d24904
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313683
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Store the page information in bit 15 of the glyph texture UV.
This code is specifically designed to only use 16-bits of
significand.
Change-Id: I36f268b5b131eaad46b05c67ffd4b7a55cfa2bde
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313519
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Note: The polarity of the staging flag is inverted from usual because
a G3 dependency with no SkUserConfig.h relies on the legacy API.
Once this lands, we will migrate them and others, then remove the
staging API. The inverted staging flag is kind of nice, actually - I may
use that pattern in the future. It means less total CLs and it's just as
easy to flip the bit on or off during debugging.
Bug: skia:104662
Change-Id: I48cba1eeae3e2e6f79918c6d243e0666e68ec71b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/310656
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
In order to expand into the correct amount of triangles, we instead
factor the matrix scale into the tolerances.
Bug: skia:10419
Change-Id: I178b9600a8837ec5fc997199a8bf6be87227ec94
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313300
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This gives us actual performance data on the cost of color management.
Change-Id: Ia74379f10791f0a8b3607c313e5108215c28b56b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313685
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, if you snapped off a shader and then changed uniforms
(without drawing & flushing), we'd trigger the SkData assert about
calling writeable_data when not-uniquely-owned. Now we lazily copy the
SkData when necessary.
Includes unit test that previously failed.
Bug: skia:10667
Change-Id: If8d9dd8106d41e66560d760cb36ed83371791fc7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313678
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Previously, early-return detection worked by ensuring that a function
had a maximum of one return statement, positioned at the end of the
function. However, this technique did not support if-else statements:
if (a) { ...; return x; } else { ...; return y; }
This meant that many simple cases were unnecessarily wrapped in a do-
while loop to handle control flow issues that didn't actually occur.
Our early-return detection logic is now more flexible and looks for any
return statements that aren't at an exit point in the control flow,
instead of looking for exactly one return at the end of the code.
Change-Id: Iffe71adf2b9349ce8de42ba8301ccc52abe2882b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313418
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkYUVAPixmapInfo is a SkYUVAInfo with per-plane color types and row
bytes. It describes a set of pixmaps that make up a planar image.
Consolidates validity checks of the SkYUVAInfo with the color types
and row bytes. It can provide SkImageInfos for each plane and also
assist with configuring planes to share a common allocation.
SkYUVAPixmaps is a collection of SkPixmaps that are valid for a
SkYUVAInfo. It can either wrap existing SkPixmaps or allocate and
own the memory. It consolidates validity checking of SkPixmaps with
the SkYUVAInfo. Replaces sk_gpu_test::YUVAPixmaps.
Minor tweaks to SkYUVAInfo naming, parameter order consistency, adds a
hasAlpha() method.
Bug: skia:10632
Change-Id: Ib0f48b8448fff22805fd0c04e07887d0b7338b76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312886
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Change-Id: Ife1f5646c0e97b666954518f8c32bb7bae926c6d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313677
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
SkBitmapProcState is the only subclass of SkBitmapProcInfo, and
BitmapProcShaderContext the only subclass of BitmapProcInfoContext.
This folds it all together, and should be a no-op refactor.
Change-Id: I971c03dbbebfcd1651ddac2f1b624329f415cc35
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313439
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Several small tweaks:
- Replace std::pair<> with a struct (IRIntrinsic) so we can use names
(fIntrinsic/fAlreadyIncluded) instead of .first and .second.
- Replace std::map<String, std::pair<...>> with a name (IRIntrinsicMap).
- Replace map with unordered_map, since we don't rely on order anywhere.
Change-Id: I508eb3cde5bd4fddcc0b3d02d6ce21d33f9a5421
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313523
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: Id5151a1a9ccf5dd3cb34d9165edff18a12459b93
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313521
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
