(instead of finishing enque before draw). The highlight is that we can now
achieve 9x speedup compared to 5x in all our previous approaches
(including multi-picture draw).
The schedulers here are experimental. I'd like to move on to try initializing
once for each draw before further polishing and optimizing the schedule
mechanism.
Bug: skia:
Change-Id: Idc3d030d475af9645c24c5372ff62b9a402206cc
Reviewed-on: https://skia-review.googlesource.com/17826
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
Change-Id: Id62e989d4278f273c040b159ed4d2fd6a2f209e0
Reviewed-on: https://skia-review.googlesource.com/18627
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
srcover_rgba_8888, lerp_u8, lerp_1_float, scale_u8, scale_1_float...
this is enough for _lots_ of drawing.
Change-Id: Ibe42adb8b1da6c66db3085851561dc9070556ee3
Reviewed-on: https://skia-review.googlesource.com/18622
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
If the ICO reports that it has a large BMP file embedded, do not
crash if we attempt to allocate too much memory.
Bug: b/38116746
Change-Id: I70eb66f5e4ffc15587007b398bbe843665eae500
Reviewed-on: https://skia-review.googlesource.com/18447
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Trying to track down why the Galaxy S6 sometimes claims that every pixel
is different, even though the zoomed images look identical. It's helpful
to draw what's actually being diffed.
Bug: skia:6653
Change-Id: Ia577aa70ed11d806fa204eaffdef41e6a65a60f2
Reviewed-on: https://skia-review.googlesource.com/18623
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
I believe this addresses the concerns of this particular bug (although more remains to be done)
Bug: skia:5327
Change-Id: Ie82f08f87b3cf3d7986fe4eeb16a5d2553173913
Reviewed-on: https://skia-review.googlesource.com/18599
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This is enough for us to do some really simple draws.
Also add some debug tools to help prioritize porting.
Change-Id: I334f8fd2133be1aeec3f3406371a81aa6c184776
Reviewed-on: https://skia-review.googlesource.com/18597
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Change-Id: Ie85ed7a807603ba627cb7f17de5a423ca9678251
Reviewed-on: https://skia-review.googlesource.com/18594
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This also makes the blend table entry for opaque src over indicate a blend of (1, ISA) rather than (1, 0) to match the actual implementation of the global src-over XP.
Change-Id: I1b1f64d2546e4f0cf03c0239ce674d1baad655f6
Reviewed-on: https://skia-review.googlesource.com/18521
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This is enough to run the bench SkRasterPipeline_compile.
$ ninja -C out monobench; and out/monobench SkRasterPipeline_compile 300
Before: 300 SkRasterPipeline_compile 48.4858ns
After: 300 SkRasterPipeline_compile 37.5801ns
Change-Id: Icb80348908dfb016826700a44566222c9f7a853c
Reviewed-on: https://skia-review.googlesource.com/18595
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We can use 2 pshufb to replace 4 unpacks when deinterlacing the colors.
Change-Id: I713fbbc94f5cb9eaf14f85323b0ec76dc2246e98
Reviewed-on: https://skia-review.googlesource.com/18531
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Bug: skia:5777
Change-Id: I3cee2ffaf1b2858e660ca5d550d25f4a312395e6
Reviewed-on: https://skia-review.googlesource.com/18589
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
It's not meant to be built as part of Skia,
only by build_stages.py into SkJumper_generated.S.
Change-Id: Id028c42355f99415fe2bc0710c2292ea949f6eec
Reviewed-on: https://skia-review.googlesource.com/18593
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
When we made start_pipeline() return void, the call into the tail!=0 run
of the pipeline became eligble to be a tail-call, and Clang made that
choice. This had the side effect of not going through vzeroupper on
those tails.
We now mark start_pipeline() as inelligible for tail calls when
targeting AVX+. All paths go through the vzeroupper at the end.
BUG=chromium:729237
Change-Id: I2099931284214f24c67b38979b3ad4b4d10e8bba
Reviewed-on: https://skia-review.googlesource.com/18591
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The content rect was always identical to the window rect,
so most of the related code did nothing. The translation
limit code is always useful (to avoid dragging the slide
way off-screen with the mouse), so always include it.
The auto-scaling to fit the screen is also still useful,
but just base it on the window rect.
The zoom code has four state variables, only used two of
them, and one was a trivially derived computation. Fold
most of that work into computeMatrix. (The translation
was always zero -- we never changed the zoom center.)
Include fDefaultMatrix in the matrix from computeMatrix,
rather than needing to apply it specially to the canvas.
Don't apply the inverse default matrix to touch or mouse
points. The absolute positions of those touch points is
not important, but because that matrix includes scale
(and sometimes very large or very small scale), it just
had the effect of greatly amplifying or damping the drag
speed. Without it, the slide always pans at the speed of
the touch/mouse drag -- which seems more desirable.
The use of the inverse default matrix was a clever trick,
but it caused the translation (applied to the global mtx)
to be scaled, so the slide was always pinned incorrectly.
Instead, supply the unmodified window rect and the default
matrix, so the trans limit code can do the obvious correct
thing: xform the slide bounds completely, then limit the
translation that will be applied after that. Slides are
now correctly pinned to screen edge regardless of how
much zoom is present in the default matrix.
Note: There are still several bugs related to all of this
code, but given the web of xform state, it's hard to
unravel. The touch gesture still doesn't know about
viewer's zoom, so that's ignored when doing the pinning.
Beyond that, it doesn't even know about window resize -
it only configures the translation limit when setting up
a slide. I had a fix for all of this (doing the
translation limiting in computeMatrix), but then the touch
gesture doesn't know about it, and can accumulate drag
motion that needs to be un-dragged to get back on-screen,
even though the slide is never really translated that far.
SkTouchGesture is in include. No one uses it except viewer:
TBR=bsalomon@google.com
Bug: skia:
Change-Id: I460cc07c3de6d36e63826f57d359faf1facf5ab3
Reviewed-on: https://skia-review.googlesource.com/18524
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: 729352
Change-Id: I5ad5e2121ce87dc154528bfd9ec0f3e9253ed792
Reviewed-on: https://skia-review.googlesource.com/18590
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
A BMP can have an arbitrarily large width. We typically read a row
into a block of memory before swizzling it to the output. Rather
than calling new to create that block of memory, which may crash
when we run out of memory, call malloc, and return null if malloc
fails.
Add a common base class for Mask and Standard BMP codecs. This class
handles allocating and freeing the buffer.
Bug: b/37623797
Change-Id: I0510b76d688d030865faa481bb2fb1351dac2c97
Reviewed-on: https://skia-review.googlesource.com/18400
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Local testing says this has been fixed by some series of SKSL changes over
the past month or so
Bug: skia:6037
Change-Id: Iffc8b63e495016ac9565459ddaf44db4049a33c0
Reviewed-on: https://skia-review.googlesource.com/14530
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
I think that I've mis-used out/Debug multiple times to build Android
viewer. Maybe this message would help me and others in the future.
No-Try: true
Docs-Preview: https://skia.org/?cl=18587
Bug: skia:
Change-Id: I810920a0ca4aa8a46dd58b35966e08513520953c
Reviewed-on: https://skia-review.googlesource.com/18587
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
For streams that are memory backed (stream->getMemoryBase() returns
a non-null ptr and hasLength() returns true), handle the stream
with skjpeg_mem_source_mgr, which directly assigns memory base to
the source manager. For other non memory backed streams, handle the
stream with skjpeg_buffered_source_mgr, which is renamed from
the old skjpeg_source_mgr with no implementation change.
Signed-off-by: cjbao <cathy.bao@intel.com>
Bug: skia:
Change-Id: I748de0bdba726bbb318922c08497135e73e37329
Reviewed-on: https://skia-review.googlesource.com/17296
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
In addition to allowing the user to supply a directory, allow them
to supply a file. Simplifies my typical use case of testing a single
file.
Change-Id: I4f268cfb33fc70ff3121135941693023b6840cd3
Reviewed-on: https://skia-review.googlesource.com/18586
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
From an off-line conversation:
The longer term idea will be to create a helper class isolates the
ability to instantiate proxies until flush time. The peek* methods
could then be moved to GrSurfaceProxy.
Change-Id: I8e8c02c098475b77d515791c0d6b81f7e4a327dd
Reviewed-on: https://skia-review.googlesource.com/18076
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This is spooky.
I don't quite yet understand why, but this makes things much faster.
Performance regressed across the board when we no longer needed the
value and changed it to return void:
https://perf.skia.org/e/?begin=1496176469&keys=6994&xbaroffset=28513
You can see similar regressions following this Chromium bug link.
BUG=chromium:729237
Change-Id: I68371b0456014f909acf819aca52aa4f4f187460
Reviewed-on: https://skia-review.googlesource.com/18580
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The default blitAntiH2() calls blitAntiH() with two length-1 runs, but
for this blitter creating a small mask is better. We can stamp both
pixels out with a single pipeline invocation.
Change-Id: If356975e85310a4545e54f2231a142d6e537944d
Reviewed-on: https://skia-review.googlesource.com/18581
Reviewed-by: Mike Reed <reed@google.com>
Since the ANGLE-side fix has landed & been rolled into Skia we no longer need this workaround.
Change-Id: I9e6296976d53fc1c87232f918a5c0257201744bf
Reviewed-on: https://skia-review.googlesource.com/18583
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Moving raw pointers does the same job as copying, but is more verbose and also
more confusing: e.g., is the supposed pointer meant to be a smart one?
This instance was flagged by the tool from
https://codereview.chromium.org/2919243002/.
BUG=chromium:729393
Change-Id: I4c89e9d80fab9f6d14ab7db53e8b9b6e7cf966dc
Reviewed-on: https://skia-review.googlesource.com/18540
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Ubuntu-Clang-x86_64-Debug-MSAN
Change-Id: I50bcb3a3d8138ce94e3741cac8ceacc9e7e28a20
Reviewed-on: https://skia-review.googlesource.com/18532
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Just 3 stages implemented so far:
load_8888
swap_rb
store_8888
That's enough to make the shortest non-trivial pipeline
that you see in the new unit test.
Change-Id: Iabf90866ab452f7183d8c8dec1405ece2db695dc
Reviewed-on: https://skia-review.googlesource.com/18458
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Also, remvoes SkNormalBevelSource as this was the last use case for the distance vector field.
Change-Id: Ib0176c78e500e6b5130310934253a75860245812
Reviewed-on: https://skia-review.googlesource.com/18482
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
In the split-opList world the full screen clear optimization no longer relies on the rendertarget ID.
Change-Id: Ifc7bf10753355a18507998e30f9de7e8c1eb57c1
Reviewed-on: https://skia-review.googlesource.com/18497
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
this is approximately a revert of https://skia-review.googlesource.com/c/17768/
I propose if/when we want to experiment with a fast-path for coherent shaders
(e.g. 2-color linear gradients, up-scaling images) that we just create a new
mechanism for shaders to opt into that, knowing that it will be driven by
the rasterpipeline (and never by the old context convention).
This CL now makes it legal/clear that a new shader subclass can *just* implement
stages for raster, and never needs to make a context.
Bug: skia:
Change-Id: I525a8b1cece100f0993f75e28128e0927a4ea35c
Reviewed-on: https://skia-review.googlesource.com/18481
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This is a no-op refator that'll help keep the interesting diff more
focused in the lowp CL. The lowp stages will use these unaltered, so
SkJumper_misc.h is a good place for them.
Change-Id: I7fb6327ade29ac884194517d94ac4303ed1079e0
Reviewed-on: https://skia-review.googlesource.com/18484
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
