Reason for revert:
guard in chrome has landed
Original issue's description:
> Revert of Change device creation to see the (optional) layer-paint (patchset #9 id:160001 of https://codereview.chromium.org/988413003/)
>
> Reason for revert:
> need to have chrome opt-in for the older API before this can land (in chrome)
>
> Original issue's description:
> > Change device creation to see the (optional) layer-paint
> >
> > Motivation:
> >
> > PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
> >
> > This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
> >
> > Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0
>
> TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/0e040f7da2fdfeb49aa60d24117306e3b1e6ea90TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1006923002
Reason for revert:
need to have chrome opt-in for the older API before this can land (in chrome)
Original issue's description:
> Change device creation to see the (optional) layer-paint
>
> Motivation:
>
> PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
>
> This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
>
> Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1008863002
Motivation:
PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
Review URL: https://codereview.chromium.org/988413003
Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
A glyph position when mapped from canvas space to device space may land
outside the bounds of the current 16 bit integer part of device space.
Device space is already limited to 32 bits for the integer part,
but for a short space in drawText and drawPosText it is currently
limited to 16 bits (SkFixed). Raise this limit by moving to 48.16.
This matches the current similar fix for measureText.
BUG=chromium:375322
Review URL: https://codereview.chromium.org/977623002
This changes SkScalarClampMax and SkScalarPin to use SkTMin and SkTMax.
This change allows compilers to more easily transform these operations
into fast max/min operarations as opposed to conditional branches.
Review URL: https://codereview.chromium.org/993593002
Clarify asColorFilter ...
1. Rename to isColorFilterNode for DAG reduction
2. Add asAColorFilter for removing the imagefilter entirely (future use-case)
Need layouttest rebaseline suppression before this can land in chrome...
https://codereview.chromium.org/984023004/
BUG=skia:
Review URL: https://codereview.chromium.org/982933002
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
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/+/fa77eb1e51b9317ff993d1be504ada173b561e5fTBR=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
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
- 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
- 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
Reason for revert:
Breaking windows bots all over the place :(
Original issue's description:
> Add SkCodec, including PNG implementation.
>
> 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.
>
> BUG=skia:3257
>
> Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49TBR=reed@google.com,djsollen@google.com,msarett@google.com,mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3257
Review URL: https://codereview.chromium.org/972743003
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.
BUG=skia:3257
Review URL: https://codereview.chromium.org/930283002
We've always been using the portable ColorRect32, so we don't need the
ColorRectProc plumbing.
Furthermore, ColorRect32 doesn't seem to be very important (we're only using
it in the opaque case, which our row-by-row procs already specialize for).
Remove that too.
If we find we want specialization for really narrow rects again, let's put it in
blitRect() directly. It's pretty unlikely we're going to get platform-specific
speedup for blits to non-contiguous memory.
My local SKP comparison is +- 3%... most neutral I've ever seen.
BUG=skia:
Review URL: https://codereview.chromium.org/959873002
There's a small window where two threads can both see the gen ID is zero,
both go get new distinct genIDs, but race to write them.
This now uses compare_exchange to read and leave the winner's ID in place
when there's a race.
SkAtomics isn't public.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/956013002
This extra atomic bool is hard to think about, and I'm worried about how
updates to fGenerationID and fUniqueGenerationID interlace. By storing
them in the same int, they can't ever race.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/955043002
Fix path bugs exposed by the path fuzzer.
Changes to existing gm and samplecode files defer their calls to construct
SkPath objects until the first draw instead of at test initialization.
Add an experimental call to SkPath to validate the internal SkPathRef.
Fix SkPath::addPoly to set the last moveto after adding a close verb.
Fix stroke to handle failures when computing the unit normal.
Add a unit test for the unit normal failure.
R=reed@google.com
Review URL: https://codereview.chromium.org/953383002
Like SkTRacy<T>, TSAN will not complain about these. Unlike SkTRacy<T>, TSAN
should not complain about these: SkAtomic<T> are threadsafe.
This should fix the races now suppressed in TSAN. As written, the memory
barriers we're using in SkPixelRef will be dumb but safe (really, dumbest
possible but safest possible). If we see a perf hit, we can follow up by
putting Ben and I in a room for a while, thinking about it really hard, and
using the minimum-strength safe memory barriers.
A refactor that steals a bit from the genID would also still be possible with
this approach.
BUG=chromium:437511
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
Review URL: https://codereview.chromium.org/955803002
Reason for revert:
This actually *does* change the public API - fID is now private, and it was being used on Android. See 5242b865d3/logs/build.log :
In file included from frameworks/base/libs/hwui/tests/../font/Font.cpp:26:0:
external/skia/src/core/SkGlyph.h: In member function 'android::uirenderer::CachedGlyphInfo* android::uirenderer::Font::cacheGlyph(const SkPaint*, glyph_t, bool)':
external/skia/src/core/SkGlyph.h:157:17: error: 'uint32_t SkGlyph::fID' is private
uint32_t fID;
^
frameworks/base/libs/hwui/tests/../font/Font.cpp:482:39: error: within this context
newGlyph->mGlyphIndex = skiaGlyph.fID;
We need to update Android in order to hide fID.
Original issue's description:
> BUG=skia:
>
> (mtklein from here on)
> No public API changes.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/f8d24e2c0c7b44b7ccf20e40890514db4cde7b15TBR=mtklein@google.com,herb@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/951353002
SK_SUPPORT_LEGACY_GET_PIXELS_ENUM just set a \#define to convert
onGetPixelsEnum
to
onGetPixels
Now that Chrome has been updated to override onGetPixels, there is no
need for the define.
BUG=skia:3257
Review URL: https://codereview.chromium.org/933853004
Swap render target of the gpu device instead of creating a new gpu
device when making a copy-on-write upon surface modification.
This removes the SkCanvas::setRootDevice which contains problematic code
when trying to increase the use of SkImages internally in Skia.
BUG=skia:3388
Review URL: https://codereview.chromium.org/925343002
Plumb SkDOM as needed to make it suitable for an SkXMLWriter backend.
Also fix a potential null typeface issue in
SkSVGDevice::AutoElement::addTextAttributes().
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/940283002
Reason for revert:
Broke callers in chrome
../../skia/ext/platform_canvas_unittest.cc:421:56: error: no member named 'isLocked' in 'SkPixelRef'
EXPECT_TRUE(platform_bitmap->GetBitmap().pixelRef()->isLocked());
Original issue's description:
> Make SkPixelRef::isLocked() debug-only, remove related dead code.
>
> DM's okay locally with no diffs, no failures.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8e65712486c66108677a9b0a55ad3e7ca94db555TBR=reed@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/940323003
All image compression currently uses (losseless) Deflate, not Jpeg.
All clients simply use SkDocument::CreatePDF(stream).
SampleApp and SkLua still use SkDocument::CreatePDF(path).
Review URL: https://codereview.chromium.org/935843007
Replace the old signature of onGetPixels (return bool) to return an
enum (Result). Remove onGetPixelsEnum.
Add a define for onGetPixelsEnum to onGetPixels. This is for staging
in Chromium, where some implementations override onGetPixelsEnum.
Add the define in skia_for_chromium_defines. Remove
SK_SUPPORT_LEGACY_IMAGE_GENERATOR_RETURN, which is no longer needed by
Chromium.
BUG=skia:3257
Review URL: https://codereview.chromium.org/939113002
Use the form SkDebugf("%s", arbitraryString) instead of
SkDebugf(arbitraryString).
Fixes the case where SkString::appendf-ing a string with "%%" and then
printing the string with SkDebugf would cause uninitialized read and
corrupted debug print.
ninja -C out/Debug tools && valgrind --leak-check=full
./out/Debug/render_pictures --config gpu -w q -r ...
...
==7307== Conditional jump or move depends on uninitialised value(s)
==7307== at 0x6908475: __printf_fp (printf_fp.c:1180)
==7307== by 0x6904267: vfprintf (vfprintf.c:1629)
==7307== by 0x6906E53: buffered_vfprintf (vfprintf.c:2313)
==7307== by 0x690188D: vfprintf (vfprintf.c:1316)
==7307== by 0x67E8F5: SkDebugf(char const*, ...) (SkDebug_stdio.cpp:18)
==7307== by 0x7983F1: GrContext::printCacheStats() const (GrTest.cpp:54)
==7307== by 0x408ECF: tool_main(int, char**) (render_pictures_main.cpp:480)
==7307== by 0x40913E: main (render_pictures_main.cpp:511)
==7307==
Budget: 2048 items 100663296 bytes
Entry Count: current 652 (651 budgeted, 0 wrapped, 297 locked, 638 scratch 32 0.000000ull), high 652
Entry Bytes: current 51087658 (budgeted 49826658, 49 0.000000ull, 1261000 unbudgeted) high 51087658
(observe "ull" instead of "% full")
(from mtklein)
This CL is not editing public API.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/943453002
Make SkImage::getTexture() const. At the moment the function
does not mutate the state.
One use-case is that this makes it possible in the future to add draw
function to SkBaseDevice functions. The device draw functions take
const ref objects, but SkGpuDevice likely would benefit of using the
getTexture().
BUG=skia:3388
R=reed@google.com
Review URL: https://codereview.chromium.org/925853002
The new enum describes the nature of the failure. This is in
preparation for writing a replacement for SkImageDecoder, which will
use this interface.
Update the comments for getPixels() to specify what it means to pass
an SkImageInfo with a different size.
Make SkImageGenerator Noncopyable.
Leave onGetYUV8Planes alone, since we have separate discussions
regarding modifying that API.
Make callers of SkImageDecoder consistently handle kPartialSuccess.
Previously, some callers considered it a failure, and others considered
it a success.
BUG=skia:3257
Review URL: https://codereview.chromium.org/919693002
