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
This makes SkComposeImageFilter::computeFastBounds compose its
filters' bounds (rather than falling back to
SkImageFilter::computeFastBounds, which takes the union of the bounds).
This also makes SkComposeImageFilter::onFilterImage correctly handle
an offset produced when applying the inner filter; such offsets were
previously ignored.
BUG=chromium:453924
Review URL: https://codereview.chromium.org/908273002
SkTHashTable is very similar to SkTDynamicHash, except it's generalized to support non-pointer value types.
It doesn't support remove(), just to keep things simple (it's not hard to add).
Instead of an iterator, it has foreach(), again, to keep things simple.
SkTHashMap<K,V> and SkTHashSet<T> build a friendlier experience on top of SkTHashTable.
BUG=skia:
Review URL: https://codereview.chromium.org/925613002
This allows for the removal of SkPath::mSourcePath on Android
as they now have a better indicator of whether or not the path
can be used again via the Java API.
Review URL: https://codereview.chromium.org/913413004
This has the side effect of requiring SkNullGLContext to use the null GL interface.
It exposes SkNullGLContext and also removes null context support from SampleApp.
Review URL: https://codereview.chromium.org/916733002
The language was being set to garbage, now set to part of the file name.
Add a test to ensure we continue to parse fallback directories correctly.
BUG=chromium:422180
Review URL: https://codereview.chromium.org/912053003
No algorithmic changes. The new APIs let us avoid a few ugly trips through void*,
and I've made the consume/acquire/release decision explicitly conditioned on TSAN.
This should fix the attached bug, which is TSAN seeing us implementing the
sk_consume_load() with a relaxed load, where we used to pass __ATOMIC_CONSUME
to TSAN. This restores us to the status quo of a couple weeks ago, where we
use relaxed loads (to avoid an extra dmb on ARM) for all setups except TSAN,
who gets the logically correct memory order, consume.
No public API changes.
TBR=reed@google.com
BUG=chromium:455606
Review URL: https://codereview.chromium.org/908943002
