More busywork so we can deprecate getGrContext.
Change-Id: I8479985334881251e6ad814d7855681df716b1da
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301542
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Since we make two jit() passes anyway (mainly for allocation size, with
stack size hinting along for the ride) we might as well feed forward
another hint, which registers we'll use in the program.
We can use this information when targeting the Windows ABI to save only
the callee-saved registers that we actually use. ARM will benefit too.
The first jit() call always saves all callee-saved registers , making
its code size a conservative estimate for the second jit() that saves
only what's needed.
This leaves some dead stack space reserved for unused registers,
but since it's O(1) and relatively small I don't really care.
I think it's an easy follow-up to tighten it up.
Change-Id: I41e71e6b2baba9c0b60ffdc303c138a54ff50dab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301534
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Instead GrTextureEffect is a special effect known by
program builders, pipeline states, etc.
Change-Id: I4436d7a10a1c3174fe1f02f136363a1c117f92fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301357
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
I've been working on only saving the callee-saved xmm registers we
actually use, and been failing a lot at it, but I think I finally
understand why and have an new approach brewing.
While I get my new approach going, this CL just salvages some of the
enter/exit refactoring from my failed attempts.
It's mostly streamlined comments. In terms of behavior it switches to
adjusting the stack pointer just once at enter and once at exit, instead
of up to twice each. This is really just finesse, and not something I'd
expect we'd ever notice.
Change-Id: I701b4c38c797d8f7cf25c84a5dfd201fc73b1f8d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301530
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Our intent is to report the number of analytic clips that have been
added; the number of fragment processors involved is an implementation
detail. (Hypothetically, an analytic clip might be represented by more
than one FP.)
Change-Id: I17484d7a69cc68b06bbbf87cb1e6fb38d5b2fb5e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301453
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I9fa9f8785f48e884cf296a638347003d1687e7c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301536
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We were assuming that there was always a vertex buffer. However,
when doing instanced draws, there's not necessarily one.
Change-Id: I870aa039b5cc552dce2644f40b933de1f62ad80b
Bug: skia:9935
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301449
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: I680cd7278d1cc0e3378991e6692098e5ce9e3efd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301447
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This may address a memory regression detected by Pinpoint, and is
conceptually more correct. If an analytic FP happened to be implemented
in terms of multiple FPs, naively counting all the child FPs wouldn't
give the right result.
Change-Id: Ia9b76f765db832f063f2730c820ebcdea3f7edb8
Bug: chromium:1097538, chromium:1102804
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301444
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Early results from measuring RSS (via /proc or similar) shows results
that aren't very accurate or stable. From previous detailed testing, I
know that mallinfo gives a good answer. We only really need results
from ~one machine, so limiting to UNIX bots isn't a big deal.
Change-Id: I73af043720b1204e1da436e2e63b19766a97a9a2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301445
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:10139
Change-Id: I379249758160ad096c9e03f25a41b00bc1987518
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301384
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This should fix the gpu-specific slides in Viewer.
Change-Id: I3ff069005bfe3639eb9608223b13c64f4c28c396
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301441
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: Ice75d0caa7b4beb2d982be094d62b54e71b45045
Bug: chromium:1101491
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301456
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
The SkPDFDocument::fTagTree::fRoot is set at document creation time.
This root will initially always be discardable, since no annotations
have been made. As a result it does not make sense to assert on it being
non-discardable, since it should be possible to create a PDF which just
happens to have no annotations added to it.
Change-Id: I2fe336c872805b6937f7c8ea275c0cb4d3438682
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301383
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
This will let us track a new metric that measures the heap usage of
constructing a default compiler object. I anticipate adding similar
stats about the heap usage from compiling simple vs. complex SkSL.
Change-Id: Idb814c0b5d210d00a06ce5dc7147437aabcba1bb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301359
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
For various reasons AutoFTAccess::face() can return nullptr,
particularly in the case of fonts backed more or less by nothing, or by
users who keep plowing on using an SkTypeface which claims not to
actually have any glyphs. Clean up all the callers to do something which
makes sense when nullptr is returned.
Bug: oss-fuzz:23862
Change-Id: Ifa8e2abbd6dc0e4f41857240c4eb95709dfe5178
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301301
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Rather than adding multiple color processors to the GrPaint, we now
use child FPs to compose the desired operation.
Change-Id: Ie4397c2ca75cb1d8a65920756355efd4e274e636
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301220
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Rather than adding multiple color processors to the GrPaint, we now
use child FPs to compose the desired operation.
Change-Id: I23a66b5c6e69d4ff6ec6f3f158e96da61f7c0cb2
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301380
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Move makeOp functionality into insertSubRunOpsIntoTarget, and remove
makeOp.
Change-Id: Icb02be321314afa56a6dc4947319b41b041a524f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301356
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Dealing with it for now; should not be allowed in the first place!
Change-Id: I52141d0543d60342c45813d35264c7ee49f1e972
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301298
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
We are replacing GrContext with the GrDirectContext/GrRecordingContext
pair. This starts making that change visible to clients (and weaning
Skia off of GrContext).
Change-Id: I00cc9bf208499984de855a1646229bd7557fc925
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300706
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
In the call insertSubRunOpsIntoTarget, the clipRect is always empty
for the distance field case.
Change-Id: Ib17eaae37a153c5b6aa473b2bf31d8b6c985e78f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301257
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This will get us closer to deprecating getGrContext.
The benches have no SkSurface::getContext calls.
TBR=bsalomon@google.com
Change-Id: I6496a6324091a75d2829bd7ee20bdbe0dc3b6fe9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300654
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
The deprecated form of `asFragmentProcessor` that did not take an
inputFP is no longer used and has been removed. The helper method
`colorFilterAcceptsInputFP` which distinguished between the forms
has also been removed.
Change-Id: Ic79198f1a734d3a7c2b0a299bc5d90e3c9b2a57f
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301019
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Runtime color filters are public API which take a color as in/out.
Changing this would be an API break. To work around this, RunInSeries
is used to invoke the inputFP, then pass its results into the runtime
color filter. This is less than ideal but allows us to preserve the
semantics that RuntimeColorFilter has historically used.
Change-Id: If973ae0f25e7610b7a4df3e4df5080f51293fd90
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301217
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This CL also makes a few minor improvements:
- Fewer calls to codeAppend[f], as each call is relatively expensive.
- Avoid calculating `fmax + fmin` repeatedly while performing RGB->HSL
conversion.
- Fixes spacing for better readability in shader panel.
Change-Id: I81b902009328765f11f8e18e1cf9edea214a4da7
Bug: skia:10217
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300781
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>
Two issues:
1) For static keyframes (start_value == end_value) AE yields horizontal
orientation (0 tangent). We technically have the same logic in
Skottie, but our value deduplication logic interferes: the two
consecutive equal values are consolidated, and the result ends up
holding the spatial lerp info for the next frame => our hold frames
auto-orient for the beginning of the next keyframe.
Fix: skip value deduplication when spatial lerp is present.
2) The very last keyframe is always static and holds no spatial info.
AE retains the orientation of the previous frame, but Skottie yields
0 tangent.
Fix: the easiest way to accomplish AE semantics is to detect when
we're dealing with the last keyframe, and swap with the previous
keyframe with an adjust weight of 1 (to select the end value). This
produces the same lerp result (because keyframed values are always
contiguous) and also respects the orientation of the prev frame.
TBR=
Change-Id: Id661f7804533e95b747722457489a7ef759572a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301176
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Change-Id: Ice46fc0bc97d6dc00e707316647d04a3137ef9f4
Bug: skia:9935
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300212
Auto-Submit: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Before I start updating this to support relocatable DDLs I felt I
should clean it up a bit.
Change-Id: I640d15a40164b33c4c2d7378e37d39fe7d3ff313
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300926
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
In order for a tagged PDF to validate, each annotation (such as
a hyperlink) must have a /StructParent entry that links back to
the Parent Tree object, which in turn links that annotation to
its corresponding struct tree node.
The parent tree also contains one entry per page. Both the page
entries and the annotation entries need IDs.
Since we don't know in advance how many pages will be in the
doc at the time we start processing annotations, we start the
annotation IDs with a large number (100,000) which effectively
serves as the maximum number of pages in a document that we can
handle.
Bug: chromium:1100712
Change-Id: I5df84c4249ed6a4d21222cfc86b2c0c9b17d6efb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300254
Auto-Submit: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
