Chrome disables these for speed and code size, so we need
to disable them to make sure our code is safe when used
this way.
int foo() {
static int32_t atomic_thing;
return sk_atomic_inc(&atomic_thing);
}
is not safe in Chrome. Making the static global is:
static int32_t atomic_thing;
int foo() {
return sk_atomic_inc(&atomic_thing);
}
BUG=skia:
Review URL: https://codereview.chromium.org/654663002
all its commands interleaved in contiguous memory. GrTBaseList also
supports extra data associated with objects, so we can store arrays
inline without having to call malloc().
Review URL: https://codereview.chromium.org/628453002
Make 'port' a flag so you can change it from the command line, making the
server more flexible and allowing us to change in which port it listen
to requests.
$ ./run_server.sh --port :8002
BUG=None
TEST=see above
R=borenet@google.com
Review URL: https://codereview.chromium.org/649663003
Consolidate read/write funcs in context.
Remove support for reading pixels from a surface that's not a target. It's currently broken and neither used nor tested.
Review URL: https://codereview.chromium.org/648863002
GCC doesn't understand -fasm-blocks or -mpascal-strings, but we don't care
about them.
While looking around in Gyp, I noticed a better way to disable warnings about
offsetof so that it doesn't tell us "disabling this warning makes no sense in C"
for every C source file we compile.
BUG=skia:
Review URL: https://codereview.chromium.org/650553002
In the new MultiPictureDraw tests a single hoisted layer is reused multiple times. The previous plot locking scheme allowed GrCachedLayer objects to be aggressively deleted prematurely leaving the reusing GrHoistedLayer objects with dangling pointers.
This CL changes adds a new pseudo-ref to GrCachedLayer. (It can't be a real ref since the cached layers aren't deleted when it goes to 0).
NOTRY=true
Committed: https://skia.googlesource.com/skia/+/5c481666c9678f43e039ad605457be3854cf8de3
Review URL: https://codereview.chromium.org/640323002
Reason for revert:
Crashing the Windows bots.
Original issue's description:
> Fix color emoji.
>
> Removes the GrMaskFormat and single atlas in GrTextStrike.
> Replaces it by storing the GrMaskFormat in each GrGlyph, and
> doing a lookup for the correct atlas based on that.
>
> Disables color glyph rendering in GrDistanceFieldTextContext
> for now.
>
> BUG=skia:2887
>
> Committed: https://skia.googlesource.com/skia/+/bc92163ddfe957ad6ffbb02ac40e0ba75ff82216TBR=robertphillips@google.com,bungeman@google.com,reed@google.com,bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2887
Review URL: https://codereview.chromium.org/640413004
Removes the GrMaskFormat and single atlas in GrTextStrike.
Replaces it by storing the GrMaskFormat in each GrGlyph, and
doing a lookup for the correct atlas based on that.
Disables color glyph rendering in GrDistanceFieldTextContext
for now.
BUG=skia:2887
Review URL: https://codereview.chromium.org/636183005
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
Reason for revert:
Failing unit tests
Original issue's description:
> Fix bug in plot locking system
>
> In the new MultiPictureDraw tests a single hoisted layer is reused multiple times. The previous plot locking scheme allowed GrCachedLayer objects to be aggressively deleted prematurely leaving the reusing GrHoistedLayer objects with dangling pointers.
>
> This CL changes the plot locking system to add a pseudo-ref for each GrHoistedLayer.
>
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/5c481666c9678f43e039ad605457be3854cf8de3TBR=jvanverth@google.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/643673004
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
