| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
R=mtklein@google.com
Review URL: https://codereview.chromium.org/982863003
|
|
|
|
|
|
|
|
|
|
| |
This blacklist entry bans any test with 'pdf' config, any source type, whose
name has '.webp' in it. In practice, that's 'image' or 'subset' source type
decoding some WEBP file.
BUG=skia:3505
Review URL: https://codereview.chromium.org/982163002
|
|
|
|
|
|
| |
BUG=skia:3505
Review URL: https://codereview.chromium.org/987533002
|
|
|
|
|
|
| |
BUG=skia:3178
Review URL: https://codereview.chromium.org/983743003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/976413002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:140001 of https://codereview.chromium.org/971803002/)
Reason for revert:
Might be breaking deps roll
Original issue's description:
> Update SkPicture cull rects with RTree information
>
> When computed, the RTree for an SkPicture will have a root
> bounds that reflects the best bounding information available,
> rather than the best estimate at the time the picture recorder
> is created. Given that creators frequently don't know ahead of
> time what will be drawn, the RTree bound is often tighter.
>
> Perf testing on Chrome indicates a small raster performance
> advantage. For upcoming painting changes in Chrome the
> performance advantage is much larger.
>
> BUG=
>
> Committed: https://skia.googlesource.com/skia/+/2dd3b6647dc726f36fd8774b3d0d2e83b493aeac
TBR=mtklein@google.com,schenney@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/977413003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core of the problem is that the system is asked to lookup the metrics for a character with id == 0. This causes a hit in the fCharToGlyphHash matching the sentinel glyph. This happens because fCharToGlpyhHash is initialized with all zeros, therefore, the fID is zero matching the char with id == 0. The fAdvanceX field of the sentinel glyph is in fact not initialized.
The bigger question is now did a zero character get passed to getUnicharMetrics?
The breaking code is basically as follows:
wchar_t glyph = L'S';
paint.measureText(&glyph, 2);
This get mischaracterized as a utf8 string instead of a utf16(?) string. Because of the little endian ordering, this is the character string 'L' '\0'. Since the size of the original string is two bytes (but a single character) the '\0' is treated as its own character and past to getUnicharMetrics.
TEST:
On windows failed using DrMemory. With this change does not fail.
BUG=463204
Review URL: https://codereview.chromium.org/977063002
|
|
|
|
|
|
|
|
|
|
| |
Also allow incomplete to be considered successful.
Do not attempt to draw transparent images on 565.
BUG=skia:3475
Review URL: https://codereview.chromium.org/978413002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Please see if this looks usable. It may even give a perf boost if you use it, even without custom implementations for each instruction set.
I've been trying this morning to beat this naive loop implementation, but so far no luck with either _SSE2.h or _SSSE3.h. It's possible this is an artifact of the microbenchmark, because we're not doing anything between the conversions. I'd like to see how this fits into real code, what assembly's generated, what the hot spots are, etc.
I've updated the tests to test these new APIs, and splintered off a pair of new benchmarks that use the new APIs. This required some minor rejiggering in the benches.
BUG=skia:
Review URL: https://codereview.chromium.org/978213003
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/987433002
|
|
|
|
|
|
|
|
|
|
|
|
| |
possible).
Change asColorFilter to reflect its reliance on the new factory behavior.
patch from issue 967143002 at patchset 80001 (http://crrev.com/967143002#ps80001)
BUG=skia:
Review URL: https://codereview.chromium.org/967833003
|
|
|
|
|
|
| |
The main thrust of this CL is to remove the currCmdMarker variable from GrTargetCommands::flush. In a MultiDrawBuffer world the Cmds need not be execute in the order of their issuance.
Review URL: https://codereview.chromium.org/978363002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/979153002
|
|
|
|
|
|
| |
Without this patch the GPU trace markers can be potentially unbalanced when batching occurs.
Review URL: https://codereview.chromium.org/981973002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tasks that produce a non-fatal error will bail out before writing their output to
disk and hash to dm.json, but not count as failures.
This also makes true failures bail out before writing their results. If the DM
program failed, we probably don't want to triage that image result.
We use this new feature first to skip image subset decoding when we detect it's
not supported. Here's a snippet of an example run, where in this case only
.webp are subset decodable:
...
( 15MB 12) 172µs 8888 subset color_wheel.jpg (skipped: Subset decoding not supported.)
( 15MB 11) 9.05ms 8888 subset randPixels.webp
( 16MB 10) 863µs 8888 subset baby_tux.png (skipped: Subset decoding not supported.)
...
Only outputs corresponding to the .webp show up, both on disk and in the .json.
BUG=skia:
Review URL: https://codereview.chromium.org/980333002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make a Via for DM which transforms a set of draws to be more like what
we'd see through the Android Framework's HWUI API. Only built inside
Android's framework because we depend on HWUI classes for half of
those transformations.
Tested with --config androidsdk-8888 and --config androidsdk-hwui.
R=djsollen@google.com,mtklein@google.com,reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/974913002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When computed, the RTree for an SkPicture will have a root
bounds that reflects the best bounding information available,
rather than the best estimate at the time the picture recorder
is created. Given that creators frequently don't know ahead of
time what will be drawn, the RTree bound is often tighter.
Perf testing on Chrome indicates a small raster performance
advantage. For upcoming painting changes in Chrome the
performance advantage is much larger.
BUG=
Review URL: https://codereview.chromium.org/971803002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/972153010
|
|
|
|
| |
Review URL: https://codereview.chromium.org/976103002
|
|
|
|
|
|
|
|
| |
BUG=skia:3484
NOTRY=true
DOCS_PREVIEW= https://skia.org/?cl=976303002
Review URL: https://codereview.chromium.org/976303002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:60001 of https://codereview.chromium.org/960783003/)
Reason for revert:
Fails on mac for some reason.
Also is a bit wrong, but this should not be reason for the failure..
Original issue's description:
> Add image as a draw type that can be filtered
>
> Add image as a draw type that can be filtered.
>
> This is needed when SkImage is added as an object to be drawn so that
> the draw is forwarded to SkBaseDevice. This would be used in making
> filters use SkImages.
>
> BUG=skia:3388
>
> Committed: https://skia.googlesource.com/skia/+/fa77eb1e51b9317ff993d1be504ada173b561e5f
TBR=reed@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3388
Review URL: https://codereview.chromium.org/980273002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add image as a draw type that can be filtered.
This is needed when SkImage is added as an object to be drawn so that
the draw is forwarded to SkBaseDevice. This would be used in making
filters use SkImages.
BUG=skia:3388
Review URL: https://codereview.chromium.org/960783003
|
|
|
|
|
|
|
|
| |
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Debug-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/975303003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/974413002
|
|
|
|
|
|
|
| |
BUG=skia:
NOTRY=True
Review URL: https://codereview.chromium.org/961933003
|
|
|
|
|
|
|
|
| |
fix casts
Committed: https://skia.googlesource.com/skia/+/9e73a84deb5e6c201081b1d30175863898543e8d
Review URL: https://codereview.chromium.org/979453004
|
|
|
|
|
|
|
|
|
|
| |
Committed: https://skia.googlesource.com/skia/+/d2ad8eb5801e2c8c0fa544a6a776bb46eedde2a0
Committed: https://skia.googlesource.com/skia/+/b2af2d8b83ca4774c3b3bb1e49bc72605faa9589
Committed: https://skia.googlesource.com/skia/+/0b70b86a7e9fda52ee7ebc1b9897eeaa09b9abef
Review URL: https://codereview.chromium.org/949263002
|
|
|
|
|
|
|
|
| |
While we work out RAM issues on Android, run everywhere else.
BUG=skia:
Review URL: https://codereview.chromium.org/971463004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/979453004/)
Reason for revert:
64-bit windows build warnings-as-errors
Original issue's description:
> (starting with mtklein's 966503002 mod to 963593003)
> fix casts
>
> Committed: https://skia.googlesource.com/skia/+/9e73a84deb5e6c201081b1d30175863898543e8d
TBR=caryclark@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/977583007
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of set(SkPMColor), add a constructor SkPMFloat(SkPMColor).
Replace setA(), setR(), etc. with a 4 float constructor.
And, promise to stick to SkPMColor order.
BUG=skia:
Review URL: https://codereview.chromium.org/977773002
|
|
|
|
|
|
| |
fix casts
Review URL: https://codereview.chromium.org/979453004
|
|
|
|
|
|
| |
R=robertphillips@google.com,reed@google.com
Review URL: https://codereview.chromium.org/979943002
|
|
|
|
|
|
| |
BUG=skia:3488
Review URL: https://codereview.chromium.org/974183002
|
|
|
|
|
|
|
|
| |
We've run into several places where GPU rasterization slows down a lot,
and in some cases, it's due to use reaching skia's budget. This shows a
graph of skia's used and free budgeted memory.
Review URL: https://codereview.chromium.org/977143002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With SSSE3, we can use the Swiss Army Knife byte shuffler pshufb,
a.k.a. _mm_shuffle_epi8(), to jump directly between 32 and 128 bits.
In microbench isolation, this looks like an additional 10-15% speedup:
SkPMFloat_get: 2.35ns -> 1.98ns
SkPMFloat_clamp: 2.35ns -> 2.18ns
Before this CL, get() and clamp() were identical code. The _get benchmark improves because both set() and get() become faster; the _clamp benchmark shows the improvement from set() getting faster with clamp() staying the same.
BUG=skia:
Review URL: https://codereview.chromium.org/976493002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:1 of https://codereview.chromium.org/973563002/)
Reason for revert:
Speculative revert to see if this unblocks the deps roll
Original issue's description:
> Adding linear interpolation to rgb->yuv conversion
>
> When the UV planes are smaller than the Y plane, doing the upscaling in nearest mode was creating artefacts, so I changed it to use linear interpolation to fix the issue.
>
> BUG=460380
>
> Committed: https://skia.googlesource.com/skia/+/cd9d42c5167a50f1bf20e969343556d61354171b
TBR=bsalomon@google.com,scroggo@google.com,reed@google.com,sugoi@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=460380
Review URL: https://codereview.chromium.org/977133002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/974883005
|
|
|
|
|
|
| |
Stumbled on this while running a trace.
Review URL: https://codereview.chromium.org/975993002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're constructing blob run paints after the canvas draw filter has been
applied.
Instead, we need do defer text blob draw filters until we have access
to the full run paints.
BUG=skia:3494
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/973973003
|
|
|
|
|
|
|
|
| |
When the UV planes are smaller than the Y plane, doing the upscaling in nearest mode was creating artefacts, so I changed it to use linear interpolation to fix the issue.
BUG=460380
Review URL: https://codereview.chromium.org/973563002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/979493002
|
|
|
|
|
|
|
|
|
| |
The previous change didn't affect Windows...
BUG=skia:3287
R=mtklein@google.com
Review URL: https://codereview.chromium.org/975803002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the fix in https://codereview.chromium.org/971243003/, to
build places that are not Android.
TBR=mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/973863002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes Android build failures.
Android builds a custom version of libpng (instead of the one
determined by skia_libpng_static) which supplies extra needed
functions.
TBR=mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/971243003
|
|
|
|
|
|
|
|
| |
This is still a bit odd in that the IoDB and TargetCommands are annoyingly interwoven. This should improve a bit when batching is everywhere.
Joshua - I think you're lead on this.
Review URL: https://codereview.chromium.org/973853002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
Review URL: https://codereview.chromium.org/963953002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DM:
Add a flag to use SkCodec instead of SkImageDecoder.
SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator
SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB
SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.
Requires a gclient sync to pull down libpng.
BUG=skia:3257
Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49
(and then reverted)
Review URL: https://codereview.chromium.org/930283002
|
|
|
|
|
|
|
|
|
|
|
| |
SSE rounds for free (that was a happy accident: they also have a truncating version).
NEON does not, nor obviously the portable code, so they add 0.5 before truncating.
NOPRESUBMIT=true
BUG=skia:
Review URL: https://codereview.chromium.org/974643002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/963953002/)
Reason for revert:
breaking iOS build.
Original issue's description:
> XPS, DM: add SkDocument::CreateXPS
>
> - SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
>
> - DM: (Windows only) an XPSSink is added, fails on non-Windows OS
>
> - DM: Common code for PDFSink::draw and XPSSink::draw are factored into
> draw_skdocument static function.
>
> - SkDocument_XPS (Windows only) implementation of SkDocument via
> SkXPSDevice.
>
> - SkDocument_XPS_None (non-Windows) returns NULL for
> SkDocument::CreateXPS().
>
> - gyp/xps.gyp refactored.
>
> - SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
>
> - SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
>
> NOPRESUBMIT=true
>
> Committed: https://skia.googlesource.com/skia/+/00d39bcbfc8394a9b48b86b04ab06ec19091fa43
TBR=reed@google.com,bungeman@google.com,mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/978443002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/963953002
|