When unique() returns true, it must also issue an acquire barrier.
Note that this change may adversly impact SkPath performance,
but editing SkPaths is already a performance issue.
BUG=chromium:258499
No API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/687293002
Any path that is generated frame-to-frame should not be rendered by using the
DistanceFieldPathRenderer, because generating the initial distance field,
uploading it and rendering it takes longer than the SoftwarePathRenderer.
BUG=skia:2935
Review URL: https://codereview.chromium.org/677463002
This is basically how blink uses the filter. Currently, I can't use it for "ShadowOnly" mode with the filter at all, but instead of copying the code and risking to have the codepaths diverge, I'm simply going to add the option here.
BUG=skia:
Review URL: https://codereview.chromium.org/646213004
Add a new enum to differentiate between a complete decode and a
partial decode (with the third value being failure). Return this
value from SkImageDecoder::onDecode (in all subclasses, plus
SkImageDecoder_empty) and ::decode.
For convenience, if the enum is treated as a boolean, success and
partial success are both considered true.
Note that the static helper functions (DecodeFile etc) still return
true and false (for one thing, this allows us to continue to use
SkImageDecoder::DecodeMemory as an SkPicture::InstallPixelRefProc in
SkPicture::CreateFromStream).
Also correctly report failure in SkASTCImageDecoder::onDecode when
SkTextureCompressor::DecompressBufferFromFormat fails.
BUG=skia:3037
BUG:b/17419670
Review URL: https://codereview.chromium.org/647023006
Currently, the PDF backend does not support image filters (since PDF
does not have that functionality), so it simply removes them. This is
causing Chrome print preview to render incorrectly (see bug). The fix
here is to fall back to a raster device for image filters, as we used
to do in Blink. The resulting bitmap will be drawn to the destination
device as a normal main-memory-backed bitmap.
Note: this change invalidates the PDF results of all GMs containing
image filters (since they'll actually be rendered).
BUG=422144
Review URL: https://codereview.chromium.org/644323006
Reason for revert:
A large number of GMs on Ubuntu12 are failing. The text layout on GPU is visibly different than that for 8888.
Original issue's description:
> Change drawText() to generate positions and send to drawPosText()
>
> The idea here is to have a central place that does layout for drawText(), and
> then always feed text through drawPosText(). This both makes all of the
> GrTextContexts consistent in drawText() output, and does a better job of
> stressing drawPosText().
>
> Because of the effect of matrices on hinting and approximation error, the
> generated text is not 100% identical to that produced by the raster pipeline.
>
> BUG=skia:2778
>
> Committed: https://skia.googlesource.com/skia/+/7851a56895c9c076f73a835a7dd51d3c6180c16fTBR=cdalton.nvidia@gmail.com,bungeman@google.com,reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2778
Review URL: https://codereview.chromium.org/659993003
The idea here is to have a central place that does layout for drawText(), and
then always feed text through drawPosText(). This both makes all of the
GrTextContexts consistent in drawText() output, and does a better job of
stressing drawPosText().
Because of the effect of matrices on hinting and approximation error, the
generated text is not 100% identical to that produced by the raster pipeline.
BUG=skia:2778
Review URL: https://codereview.chromium.org/653133004
A careful reading of the preprocessor specification indicates that
any use of the 'defined' operator outside the form of 'defined X' or
'defined ( X )' directly in the constant expression of a '#if' or
'#elif' may cause undefined behavior.
In particular, msvc is very unpredictable. The 'defined X' and
'defined ( X )' forms behave differently when created from marco
expansion, with 'defined ( X )' generally evaluating to '0L'. The
'defined X' form generally behaves more the way one would expect,
but still has a number of quirks which should simply be considered
undefined behavior.
BUG=chromium:419245
Review URL: https://codereview.chromium.org/657183002
Function- or method- local scope isn't threadsafe; the pointer is generally
zero-initialized on first use in function scope (i.e. lazily... we have to go
deeper), but for globals we can be pretty sure the linker will do that for us.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/651723003
Before getting too far into changing how SkTileGrid stores its tiles, I figured I'd
better see how much I can tweak out the existing format. Cleverly, that way
any improvements I make by changing the format will look that much less
impressive.
This CL looks like it will be a 5-15% win in time spent recording, with no effect
on playback.
This CL also shrinks the tiles to fit exactly when we're done inserting,
using newly added SkTDArray::shrinkToFit(). It's quite cheap to run (maybe
taking back 1-2% from those 5-15% wins), and means we'll lug around about 15%
fewer bytes in the tile grids. Note though this strategy temporarily uses up to
30% more memory while building the tile grid. For our largest SKPs, that's
maybe 75-100K extra.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/52455cbc02d7f480d988ae7cdacc11ad69078c2c
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot
Review URL: https://codereview.chromium.org/639823005
Reason for revert:
failed assertion "fXTiles * fYTiles != 0"
Original issue's description:
> Use BBH reserve hook to preallocate space for tiles.
>
> Before getting too far into changing how SkTileGrid stores its tiles, I figured I'd
> better see how much I can tweak out the existing format. Cleverly, that way
> any improvements I make by changing the format will look that much less
> impressive.
>
> This CL looks like it will be a 5-15% win in time spent recording, with no effect
> on playback.
>
> This CL also shrinks the tiles to fit exactly when we're done inserting,
> using newly added SkTDArray::shrinkToFit(). It's quite cheap to run (maybe
> taking back 1-2% from those 5-15% wins), and means we'll lug around about 15%
> fewer bytes in the tile grids. Note though this strategy temporarily uses up to
> 30% more memory while building the tile grid. For our largest SKPs, that's
> maybe 75-100K extra.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/52455cbc02d7f480d988ae7cdacc11ad69078c2cTBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/642933002
Before getting too far into changing how SkTileGrid stores its tiles, I figured I'd
better see how much I can tweak out the existing format. Cleverly, that way
any improvements I make by changing the format will look that much less
impressive.
This CL looks like it will be a 5-15% win in time spent recording, with no effect
on playback.
This CL also shrinks the tiles to fit exactly when we're done inserting,
using newly added SkTDArray::shrinkToFit(). It's quite cheap to run (maybe
taking back 1-2% from those 5-15% wins), and means we'll lug around about 15%
fewer bytes in the tile grids. Note though this strategy temporarily uses up to
30% more memory while building the tile grid. For our largest SKPs, that's
maybe 75-100K extra.
BUG=skia:
Review URL: https://codereview.chromium.org/639823005
This removes:
1) ability to record old pictures with SkPictureRecorder;
2) a couple tests specific to the old backend.
The functionality of DEPRECATED_beginRecording() now lives in
(private) SkPicture::Backport(), which is the only place we
need it now.
BUG=skia:
TBR=reed@google.com
Review URL: https://codereview.chromium.org/618303002
Having hoisted layers from different pictures invalidates the assumptions of the old GrReplacements object. This is fixed by switching to a SkTDynamicHash-based back-end.
Sub-picture-layers also require that the replacement drawing occur for the sub-pictures too. The ReplaceDraw object is added to make this happen and limit the replacement lookup to saveLayer draw commands.
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
Review URL: https://codereview.chromium.org/607763008
Feature-wise, this removes:
1) BBH support;
2) peephole optimizations;
3) record-time text op specializations;
4) the guarantee that SkPaints are flattened.
This deletes the optimizations GM, which only exists to test the peepholes of
the old backend. SkRecord optimizations are unit tested, and if that ever fails we
can think about adding another GM like this, but they're different enough we'd
want to start from scratch anyway.
We need to keep the code that plays back the specialized text ops around for
a while for compatibility with existing .SKPs that have those ops recorded.
BUG=skia:
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/617953002
