We allow this to be raced on, and it may have already become not-dirty by the
time we get to this function if computed by another thread.
BUG=skia:
Review URL: https://codereview.chromium.org/398913002
This flag was only used when setting or checking SkBitmap's
immutability when it did not have an SkPixelRef. Now that an
SkBitmap *must* have one in order to draw (e.g. you can no
longer have an SkBitmap that owns its pixels directly), its
immutabity without an SkPixelRef makes no sense.
Also, now that the flags are not contiguous starting from
0x01, use a more appropriate check to ensure only meaningful
flags are used.
R=reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/387083002
The base class, SkCanvasState, now holds the version, width, and
height. These fields will always be a necessary part of the class.
(Also add in some padding.)
The other fields, which may change, have been moved into the
subclass, SkCanvasState_v1. If/when the version changes, it will
correspond to a new subclass.
In SkCanvasStateUtils::CreateFromCanvasState, check the version on
the base class, then do a static_cast to the version corresponding
to SkCanvasState::version.
Remove CANVAS_STATE_VERSION, which is redundant with the version
specified by the subclass.
Use unambiguous type for rowBytes.
Build Android with SK_SUPPORT_LEGACY_CLIPTOLAYERFLAG. This allows us
to run the full suite of CanvasState tests. It is also representative
of what will be used on Android by WebView.
Fix CanvasStateTest where it was broken inside ifdef'ed out code.
Use SkCanvas::getBaseLayerSize() instead of the deprecated
SkCanvas::getDeviceSize().
Update the comments in the header to be more clear. In particular,
an SkCanvasState can only be used to pass an SkCanvas' state to a
future version of Skia (or the same); not an older version.
NOTREECHECKS=true
BUG=b/15693384
R=reed@google.com, mtklein@google.com, djsollen@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/372003002
skia_ios.mm
Get the app's Documents directory and pass use it to set the resource path.
This is a quick hack which will be replaced by a new application that is
a tiny shim around a command line tool.
SkImageEncoder.h
SkForceLinking.cpp
SkImageDecoder_CG.cpp
Add support for FORCE_LINKING so iOS sees the PNG encoder and others.
SkFloatBits.cpp
SkPoint.cpp
Handle denormalized numbers that are floored by the iOS ARM processor.
SkImageDecoder_iOS.mm
Remove empty encoder factory.
SkTouchGesture.cpp
Return early on empty state on touch rather than aborting (crashing)
JpegTest.cpp
Hal via stackoverflow.com says partial jpegs can be gray as well.
skia_test.cpp
Remove crash handler call for now to avoid link failure.
OverwriteLine.h
Remove fancy line overwrite for iOS.
Resources.cpp
Add interface to set resource directory based on runtime query.
BUG=skia:2736 skia:2737 skia:2738
R=reed@google.com, halcanary@google.com, mtklein@google.com, tfarina@chromium.org
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/373383003
Reason for revert:
Going to try to just remove the many-at-once clone interface
Original issue's description:
> Add alternate SkPicture::clone
>
> This adds an alternate version of SkPicture::clone for two reasons:
>
> 1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor)
>
> 2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely.
>
> Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/)
>
> Committed: https://skia.googlesource.com/skia/+/e372e78223a8ce916d276d6e0420d552fb0267e9R=mtklein@google.com, reed@google.comTBR=mtklein@google.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/386933004
This adds an alternate version of SkPicture::clone for two reasons:
1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor)
2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely.
Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/)
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/381193002
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot,Canary-Chrome-Win7-Ninja-x86-SharedLib_ToT-Trybot,Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
Reason for revert:
hidden symbol 'AnnotateBenignRaceSized' in obj/base/third_party/dynamic_annotations/libdynamic_annotations.a(obj/base/third_party/dynamic_annotations/dynamic_annotations.dynamic_annotations.o) is referenced by DSO lib/libblink_platform.so
Original issue's description:
> Add SkRacy
>
> SkRacy<T> is a zero-overhead wrapper for a T, except it also
> silences race warnings when TSAN is running.
>
> Here we apply in several classes. In SkMatrix and SkPathRef,
> we use it to opportunistically cache some idempotent work.
>
> In SkPixelRef, we wrap the genIDs. We think the worst that
> can happen here is we'll increment the global next-genID a
> few times instead of once when we go to get another ID.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7R=reed@google.com, mtklein@chromium.orgTBR=mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/377693005
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
This CL begins setting up the SkPicturePlayback split by simplifying the class and componentizing it a bit. It:
fuses SkPictureData::OperationList into SkPicture::OperationList
adds a handleOp method to SkPicturePlayback that can be reused by derived classes
removes a couple debugging tools (ENABLE_TIME_DRAW & SPEW_CLIP_SKIPPING)
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/378703002
This splits the playback functionality out of SkPictureData. The old SkPictureData::draw method is pulled out along
with its supporting functions as verbatim as possible. Some follow on CLs will be required to:
re-enable profiling in the debugger (and remove the vestiges of SkTimedPicture)
re-enable display of command offsets in the picture (this should probably wait until we've switched to SkRecord though)
Clean up CachedOperationList (maybe fuse with SkPicture::OperationList)
Split SkPicturePlayback into a base class and two derived classes
Implement parallel version of GatherGPUInfo for SkRecord
Landing this is blocked on removing Android's use of the abortPlayback entry point.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/377623002
Add OpenGL ES extension functions needed to support NV_path_rendering in OpenGL
ES.
The added glProgramPathFragmentInputGenNV call is defined in NV_path_rendering
revision 30, similar to following:
Append to the end of the "Shader Inputs" subsection of Section 3.12.2
"Shader Execution":
The command
void ProgramPathFragmentInputGenNV(uint program,
int location,
enum genMode,
int components,
const float *coeffs);
controls how a user-defined (non-built-in) fragment input of a
GLSL program object is computed for fragment shading operations that
occur as a result of CoverFillPathNV or CoverStrokePathNV.
/program/ names a GLSL program object. If /program/ has not been
successfully linked, the error INVALID_OPERATION is generated.
The given fragment input generation state is loaded into the fragment
input variable location identified by /location/. This location
is a value returned either by GetProgramResourceLocation with a
/programInterface/ of FRAGMENT_INPUT_NV and a given fragment shader
input variable name or by GetProgramResourceiv with FRAGMENT_INPUT_NV
for the /programInterface/ and LOCATION for the property for a given
fragment input resource index.
....
glProgramPathFragmentInputGenNV will be used instead of glPathTexGen,
because the latter depends on fixed function pipeline that is not
exposed in ES.
Also add glGetProgramResourceLocation from OpenGL 4.3 or
ARB_program_interface_query.
Also add FRAGMENT_INPUT define to be used with glGetProgramResourceLocation.
The added functions are not used yet, but they're needed when implementing
NV_path_rendering support for OpenGL ES. They can also be used on OpenGL.
Remove uncalled NV_path_rendering functions, so they do not cause confusion
or take space in the interface definition. The ones that are later used
can be re-added when needed.
Remove definitions NV_path_rendering that are for NV_path_rendering function
parameters that are not used. The ones that are later used
can be re-added when needed.
Committed: https://skia.googlesource.com/skia/+/4a995dfff2ecf91e8bf999d77e3218cec596232cR=bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/345723002
Move SkBitmap's validate_alphaType to SkImageInfo, with the new
name SkColorTypeValidateAlphaType. Use it in SkPixelRef's constructors,
as well as in SkDecodingImageGenerator. This fixes a bug where an
SkPixelRef's SkAlphaType could get out of sync with its SkBitmap,
when both were assigned the same SkAlphaType.
R=reed@google.com, halcanary@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/346593003
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111bR=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
Reason for revert:
Sigh
Original issue's description:
> Begin atlasing
>
> This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
>
> 1) the atlased layers cannot be purged nor aged out
> 2) the texture backing the atlas is not pulled from (or returned to) the resource cache
>
> #1 is on hold until we have a recycling rectanizer
>
> A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
>
> Committed: https://skia.googlesource.com/skia/+/55e61f0ef4e5c8c34ac107deaadc9b4ffef3111bR=bsalomon@google.comTBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/359953002
This CL makes it possible for pulled-forward-layers to be atlased. It currently has a couple glaring limitations (which is why it is disabled):
1) the atlased layers cannot be purged nor aged out
2) the texture backing the atlas is not pulled from (or returned to) the resource cache
#1 is on hold until we have a recycling rectanizer
A separate major limitation (the non-atlased layers aren't cached) is blocked until we can transmute entries in the resource cache from scratch to non-scratch while potentially preserving their contents.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/354533004
When drawing perlin noise, generate noise at the resolution determined
by CTM, not by the resolution at construction time. This required moving
the generation of PaintingData to getContext() and asNewEffect() for the
raster and GPU paths, respectively.
It also required adjusting the matrices used during rendering
to be translate-only.
R=sugoi@chromium.org, bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/358903002