Implements:
* Event loop event waiting (no busy loop)
** Skia timers
* Proper window sizing and resizing
* MSAA on X11 (previously it did not use MSAA at all)
* Changes requested colorspace from 565 to 8888
to match non-SDL variants
* Context creation clearing (color and stencil mask)
* Opens the window in 640x480 by default on desktop.
Removes dead code.
BUG=skia:4733
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1578173002
Review URL: https://codereview.chromium.org/1578173002
Try to start faster:
- remove flags dependency
- print nothing
- strip unused symbols from the binary on Mac (smaller binary)
- only create one fuzz object
- only run one DEF_FUZZ
I am not sure if any of these things mattered, but I thought you may like to look.
Good stuff:
- make nextU() / nextF() work
- drop nextURange() / nextFRange() for now
- add nextB() for a single byte
As you may have guessed, I have figured out how to use afl-fuzz on my laptop.
Syntax to run becomes:
$ afl-fuzz ... out/Release/fuzz <DEF_FUZZ name> @@
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1581203003
Review URL: https://codereview.chromium.org/1581203003
Simplify path id allocation in NVPR backend. Instead of using
an AVL tree of path id ranges for the first 65535 ids, use just
a simple stategy of overallocation and "bump index".
Fixes the bug where previously overallocated ids were not deleted.
The advantage is that the implementation is simple and all allocations
go through overallocation, not just the first 65535 of the 1-range
allocations.
Removes the logic where paths were cleared with setting path data to
null instead of deleting the whole path. Now deleted paths are just
deleted normally. These operations should have equivalent performance on
command buffer. Deleting the path should enable the driver to do more
maintainance.
Removes the GLNameAllocator, as it was only used for paths. In order for
it to be used for other IDs, it probably would need to be re-written to
support cleanup and arbitrary ranges. Also, the interface would probably
need to be changed to not requiring the block to be allocated before it
could be managed by the structure.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1150243003
Review URL: https://codereview.chromium.org/1150243003
Improves decode performance for RGBA encoded PNGs.
Swizzle Time on Nexus 9 (with clang):
SwapPremul 0.44x
Premul 0.44x
Decode Time On Nexus 9 (with clang):
ZeroInit Decodes 0.85x
Regular Decodes 0.86x
Swizzle Time on Nexus 6P (with clang)
SwapPremul 0.14x
Premul 0.14x
Decode Time On Nexus 6P (with clang):
ZeroInit Decodes 0.93x
Regular Decodes 0.95x
Notes:
ZeroInit means memory is zero initialized, and we do not write to
memory for large sections of zero pixels (memory use opt for Android).
A profile on Nexus 9 shows that the premultiplication step of PNG
decoding is now ~5% of decode time (down from ~20%).
BUG=skia:4767
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1577703006
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1577703006
The GPU fast path was not doing the correct thing for input bitmaps of
differing sizes. This change brings the fast path in line with the
slow path: use the union of foreground and background bounds as bounds,
offset the draw context by the bounds translation, and translate the
foreground and background independently by their respective offsets.
Finally, we add a texture domain for the background fragment
processor, since we may access texels outside its domain.
Note: this adds two new test cases to the xfermodeimagefilter GM, so
those will need to be rebaselined.
BUG=568196
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1588633002
Review URL: https://codereview.chromium.org/1588633002
Part of this CL improves the speed by using dynamic arrays
more effectively.
Part uses SIMD and more concise float expressions for speed.
Some unused code was deleted.
The latter changes are guarded by:
SK_SUPPORT_LEGACY_BITMAP_FILTER
until this lands and the corresponding layout changes in
chrome can be relanded.
With the legacy flag defined, no Skia or Chrome test results
change. Without the flag defined in Skia, only 0.01% - 0.02%
of the pixels change, and then by (1,1,1) in 8888.
codereview.chromium.org/1583533002 adds the guard to Chrome.
R=reed@google.com
BUG=skia:2261
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1563183003
Review URL: https://codereview.chromium.org/1563183003
If the input bitmap passed to SkTileImageFilter does not fill the
srcRect, we were tiling this incorrectly (see the first sample
from tileimage filter -- it draws from a srcRect of 12,12 50x50
to a dstRect of 0,0 50x50. There should be no tiling at all
in this case!)
In order to fix this, we need to pad the bitmap out to srcRect,
and tile with that. In order to tile correctly in the GPU case,
we need to request a tileable texture.
NOTE: this will change the results of the tileimagefilter GM (correctness,
and added src / dest rects).
BUG=skia:4774
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1570133003
Review URL: https://codereview.chromium.org/1570133003
I figure something like this lets us not worry about it in the new opts.
This skips only leading zeros per-scanline, not all zeros, but my bet is that
leading zeros are all that matters: it's got to be rare that a scanline is both
larger than 1024 pixels and has runs of 1024 transparent pixels in the middle.
I bet the big bang for the buck comes from skipping full scanlines (or even
multiple adjacent scanlines).
BUG=skia:4767
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1566653007
Review URL: https://codereview.chromium.org/1566653007
