Bug: skia:
Change-Id: I8c91cfdb89e4f22448d1201d391556fe43d86dca
Reviewed-on: https://skia-review.googlesource.com/105289
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Cary Clark <caryclark@google.com>
Update includes to fix minor edits
and bookmaker bugs.
Also update SkPoint.h for the first
time to see if that sticks.
TBR=reed@google.com
Bug: skia:6898
Change-Id: I7d11dea45482602248e2d15b05699bb4c86ea4c6
Reviewed-on: https://skia-review.googlesource.com/90541
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
The latest, minor changes on includes already
generated, plus four new ones.
TBR=reed@google.com
Bug: skia:6898
Change-Id: If06ae9b9aaa3a0a9fae570aa7a6698ff340c43b8
Reviewed-on: https://skia-review.googlesource.com/62862
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
This reverts commit 88757dacd4.
Reason for revert: Still seems to be failing Chromium "telemetry_perf_unittests (with patch) on Android" on android_n5x_swarming_rel.
Original change's description:
> guard old apis for querying byte-size of a bitmap/imageinfo/pixmap
>
> Now with legacy behavior for allocpixels
>
> This was reverted, so the current CL is a "fix" on top of ...
> https://skia-review.googlesource.com/c/skia/+/50980
>
> Related update to Chrome (in preparation for this change)
> https://chromium-review.googlesource.com/c/chromium/src/+/685719
>
> Bug: skia:
> Change-Id: I4b370ee7e95083ab27421f008132219c9c7b86e9
> Reviewed-on: https://skia-review.googlesource.com/51341
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=fmalita@chromium.org,reed@google.com
Change-Id: I827a0ca1d1e3909e648fde3342cdb8601d34da8d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/52381
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This reverts commit 98a6216b18.
Reason for revert: breaking the chrome roll. Looks like they may be writing data to create an image across all the row bytes and thus writing to unalloced data on the last row. Link to example failing bot:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/539960
Original change's description:
> guard old apis for querying byte-size of a bitmap/imageinfo/pixmap
>
> Previously we had size_t and uint64_t variations.
>
> The new (simpler) API always..
> - returns size_t, or 0 if the calculation overflowed
> - returns the trimmed size (does not include rowBytes padding for the last row)
>
> Bug: skia:
> Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e
> Reviewed-on: https://skia-review.googlesource.com/50980
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Reviewed-by: Leon Scroggins <scroggo@google.com>
TBR=mtklein@google.com,herb@google.com,scroggo@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I726f6ab1b36b14979ba6f37105e0a469b3f0dbc0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/51262
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Previously we had size_t and uint64_t variations.
The new (simpler) API always..
- returns size_t, or 0 if the calculation overflowed
- returns the trimmed size (does not include rowBytes padding for the last row)
Bug: skia:
Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e
Reviewed-on: https://skia-review.googlesource.com/50980
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Fresh off the griddle versions of:
SkPaint.h, SkCanvas.h, SkPath.h, and SkPixmap.h.
TBR=reed@google.com
Bug: skia: 9868
Change-Id: If3f0c1cd7973c53482772c2478b12f1070c9fc4d
Reviewed-on: https://skia-review.googlesource.com/46587
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Cary Clark <caryclark@skia.org>
a couple of missing names
trip up bookmaker
TBR=reed@google.com
Bug: skia: 6898
Change-Id: I224f3a0422474cb6d4d3558abb3e800d5abedd12
Reviewed-on: https://skia-review.googlesource.com/46580
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
void reset(const SkImageInfo& info)
is not useful because it sets
rowBytes to zero while leaving
width alone.
This form of reset also doesn't
appear to have a caller.
TBR=reed@google.com
Bug: skia: 6898
Change-Id: I87019420ddc59107aefe0cac27a6b969976f1bf6
Reviewed-on: https://skia-review.googlesource.com/43480
Reviewed-by: Cary Clark <caryclark@skia.org>
Commit-Queue: Cary Clark <caryclark@skia.org>
SkPixmap.h is missing a couple
of parameter names. Named parameters
helps bookmaker generate markdown
and doxygen that describe methods
and functions.
TBR=reed@google.com
Bug: skia:6898
Change-Id: I8f9e1acd677e57e71c26c34759ce4647a5db0548
Reviewed-on: https://skia-review.googlesource.com/42380
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
This was created by looking at warnings produced by clang's
-Wzero-as-null-pointer-constant. This updates most issues in
Skia code. However, there are places where GL and Vulkan want
pointer values which are explicitly 0, external headers which
use NULL directly, and possibly more uses in un-compiled
sources (for other platforms).
Change-Id: Id22fbac04d5c53497a53d734f0896b4f06fe8345
Reviewed-on: https://skia-review.googlesource.com/39521
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Lots more changes coming later (need to remove colortable parameters from bitmaps and pixmaps)
Bug: skia:6828
Change-Id: Ic63e89570644839fab068141f49915b3f66d1053
Reviewed-on: https://skia-review.googlesource.com/24127
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Needs google3 to be updated before this can land.
Bug: skia:6828
Change-Id: I2c16be13c6937ffa48768cc24f9f980171c824d6
Reviewed-on: https://skia-review.googlesource.com/23940
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This should be immediately useful in the Skia-Android
rendering pipeline.
Possible future uses include creating a "renderable"
SkImage from a bitmap with a funny color space.
Inspired by:
https://skia-review.googlesource.com/c/13981/
Bug: b/62347704
Change-Id: I388c7af1fc43834b8ad22022d0caf3ac90b734c8
Reviewed-on: https://skia-review.googlesource.com/18598
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
guarded by SK_SUPPORT_OBSOLETE_LOCKPIXELS
needs https://codereview.chromium.org/2820873002/# to land first
Bug: skia:6481
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Reviewed-on: https://skia-review.googlesource.com/13580
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
It has been incorrectly interpreting its SkColor as sRGB all the time. Now, we plumb through the destintation color space and some scratch space, letting it decide how to interpret its SkColor later when it knows about the dst color space. The scratch space is blitter scoped, which lets this be thread safe (this is much like SkShader::Context).
This only corrects the gamma transformation for now. I've kept my previous TODO about gamut transformation. Everything assumes sRGB gamut for now.
Shaders will get the same treatement in this pipeline.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4725
Change-Id: I55b0c7d5db9ad8d7dcdd6295c9dac61d10aeaed4
Reviewed-on: https://skia-review.googlesource.com/4725
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
SkSurface_Raster snapshots do not lock their backing bitmaps when the
pixel ref is shared - they only lock on deep-copy.
But since for raster surfaces the pixels are always in memory, I think
it would be OK to also lock in the former case.
This allows for optimized (zero-copy) reads of raster surface snapshot
data.
R=reed@google.com
Review URL: https://codereview.chromium.org/1256993002
