| Age | Commit message (Collapse) | Author |
|---|
|
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The old ioutil references are still valid, but update our code
to reflect best practices and get used to the new locations.
Code compiled with the bootstrap toolchain
(cmd/asm, cmd/dist, cmd/compile, debug/elf)
must remain Go 1.4-compatible and is excluded.
Also excluded vendored code.
For #41190.
Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/263142
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
Change-Id: I98f5d987b92a29dcff06ae23b92f293cc7d6c02f
Reviewed-on: https://go-review.googlesource.com/c/go/+/252597
Reviewed-by: David Symonds <dsymonds@golang.org>
|
|
The two existing benchmarks encode randomized pixels, which isn't very
representative. The two new benchmarks encode a PNG photo as a GIF.
Also rename the benchmarks for consistency.
Also fix the bytes-per-op measure for paletted images, which are 1 (not
4) bytes per pixel.
Also simplify BenchmarkEncodeRandomPaletted (formerly just called
BenchmarkEncode). It doesn't need to generate a random palette (and the
GIF encoder largely doesn't care about the palette's RGBA values).
Use palette.Plan9 instead, a pre-existing 256-element color palette.
Change-Id: I10a6ea4e9590bb0d9f76e8cc0f4a88d43b1d650d
Reviewed-on: https://go-review.googlesource.com/c/go/+/248218
Reviewed-by: David Symonds <dsymonds@golang.org>
|
|
The benchmark throughput numbers don't change, but the set-up time (the
time taken before the b.ResetTimer() call) drops from 460ms to 4ms.
Change-Id: I5a6756643dff6127f6d902455d83459c084834fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/237757
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Before this commit, the code declares and assigns "n" with the result of
io.ReadFull() -- but the value is not used. The variable is then reused
later in the function.
This commit removes the first declaration of "n" and declares it closer
to where it is used.
Change-Id: I7ffe19a10f2a563c306bb6fe6562493435b9dc5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/232917
Reviewed-by: Rob Pike <r@golang.org>
|
|
Prior to this commit, NewXxx could panic when passed an image.Rectangle
with one of width or height being negative. But it might not panic if
both were negative, because (bpp * w * h) could still be positive. After
this commit, it will panic if both are negative.
With overflow, NewXxx might not have panicked if (bpp * w * h), the
length passed to "make([]uint8, length)", was still non-negative (after
truncation), but even if w and h were valid (non-negative), the overall
byte slice wasn't long enough. Iterating over the pixels would possibly
panic later with index out of bounds. This change moves the panic
earlier, closer to where the mistake is.
Change-Id: I011feb2d53515fc3f0fe72bb6c23b3953772c577
Reviewed-on: https://go-review.googlesource.com/c/go/+/230220
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #28717
Change-Id: I0a1e4ef1583fff89b6f46ef647fb6e4499bdf999
Reviewed-on: https://go-review.googlesource.com/c/go/+/230122
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #38739
Change-Id: I42b9b601e63ab8df69a0e5ce9bcabf75bb98d83e
Reviewed-on: https://go-review.googlesource.com/c/go/+/230777
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
name old time/op new time/op delta
PalettedFill-4 5.74ms ± 1% 0.01ms ± 1% -99.78% (p=0.008 n=5+5)
PalettedRGBA-4 3.34ms ± 3% 3.33ms ± 0% ~ (p=0.690 n=5+5)
Fixes #35938
Thanks to pjbgtnj for the suggestion.
Change-Id: I07b494482cce918f556e196c5a4b481b4c16de3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/230118
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #38435
Change-Id: Ib9ae3cf7f338b2860a5688e448a125f257fe624e
Reviewed-on: https://go-review.googlesource.com/c/go/+/230219
Reviewed-by: Andrew Ekstedt <andrew.ekstedt@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Use the following (suboptimal) script to obtain a list of possible
typos:
#!/usr/bin/env sh
set -x
git ls-files |\
grep -e '\.\(c\|cc\|go\)$' |\
xargs -n 1\
awk\
'/\/\// { gsub(/.*\/\//, ""); print; } /\/\*/, /\*\// { gsub(/.*\/\*/, ""); gsub(/\*\/.*/, ""); }' |\
hunspell -d en_US -l |\
grep '^[[:upper:]]\{0,1\}[[:lower:]]\{1,\}$' |\
grep -v -e '^.\{1,4\}$' -e '^.\{16,\}$' |\
sort -f |\
uniq -c |\
awk '$1 == 1 { print $2; }'
Then, go through the results manually and fix the most obvious typos in
the non-vendored code.
Change-Id: I3cb5830a176850e1a0584b8a40b47bde7b260eae
Reviewed-on: https://go-review.googlesource.com/c/go/+/193848
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
The existing implementation has calculated pixels per byte for each pixel.
reduce the calculation of pixels per byte.
name old time/op new time/op delta
EncodeGray-4 2.16ms ± 1% 2.16ms ± 1% -0.28% (p=0.000 n=86+84)
EncodeGrayWithBufferPool-4 1.99ms ± 0% 1.97ms ± 0% -0.72% (p=0.000 n=97+92)
EncodeNRGBOpaque-4 6.51ms ± 1% 6.48ms ± 1% -0.45% (p=0.000 n=90+85)
EncodeNRGBA-4 7.33ms ± 1% 7.28ms ± 0% -0.69% (p=0.000 n=89+87)
EncodePaletted-4 5.10ms ± 1% 2.29ms ± 0% -55.11% (p=0.000 n=90+85)
EncodeRGBOpaque-4 6.51ms ± 1% 6.51ms ± 0% ~ (p=0.311 n=94+88)
EncodeRGBA-4 24.3ms ± 2% 24.1ms ± 1% -0.87% (p=0.000 n=91+91)
name old speed new speed delta
EncodeGray-4 142MB/s ± 1% 143MB/s ± 1% +0.26% (p=0.000 n=86+85)
EncodeGrayWithBufferPool-4 154MB/s ± 0% 156MB/s ± 0% +0.73% (p=0.000 n=97+92)
EncodeNRGBOpaque-4 189MB/s ± 1% 190MB/s ± 1% +0.44% (p=0.000 n=90+86)
EncodeNRGBA-4 168MB/s ± 1% 169MB/s ± 0% +0.69% (p=0.000 n=89+87)
EncodePaletted-4 60.3MB/s ± 1% 134.2MB/s ± 0% +122.74% (p=0.000 n=90+85)
EncodeRGBOpaque-4 189MB/s ± 1% 189MB/s ± 0% ~ (p=0.326 n=94+88)
EncodeRGBA-4 50.6MB/s ± 2% 51.1MB/s ± 1% +0.87% (p=0.000 n=91+91)
name old alloc/op new alloc/op delta
EncodeGray-4 852kB ± 0% 852kB ± 0% +0.00% (p=0.000 n=100+100)
EncodeGrayWithBufferPool-4 1.49kB ± 2% 1.47kB ± 1% -0.88% (p=0.000 n=95+90)
EncodeNRGBOpaque-4 860kB ± 0% 860kB ± 0% +0.00% (p=0.003 n=98+58)
EncodeNRGBA-4 864kB ± 0% 864kB ± 0% +0.00% (p=0.021 n=100+99)
EncodePaletted-4 849kB ± 0% 849kB ± 0% +0.00% (p=0.040 n=100+100)
EncodeRGBOpaque-4 860kB ± 0% 860kB ± 0% ~ (p=0.062 n=66+98)
EncodeRGBA-4 3.32MB ± 0% 3.32MB ± 0% -0.00% (p=0.044 n=99+99)
name old allocs/op new allocs/op delta
EncodeGray-4 32.0 ± 0% 32.0 ± 0% ~ (all equal)
EncodeGrayWithBufferPool-4 3.00 ± 0% 3.00 ± 0% ~ (all equal)
EncodeNRGBOpaque-4 32.0 ± 0% 32.0 ± 0% ~ (all equal)
EncodeNRGBA-4 32.0 ± 0% 32.0 ± 0% ~ (all equal)
EncodePaletted-4 36.0 ± 0% 36.0 ± 0% ~ (all equal)
EncodeRGBOpaque-4 32.0 ± 0% 32.0 ± 0% ~ (all equal)
EncodeRGBA-4 614k ± 0% 614k ± 0% ~ (all equal)
Change-Id: I716bde2dc80d8111d75d3d765fc09223f770d5a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/187417
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: Ic5b01c0a6912d87e812331d6525939df8f525cca
GitHub-Last-Rev: b6ffefcf8f2ec1ed7ee13f36e8fef6af965ba332
GitHub-Pull-Request: golang/go#29993
Reviewed-on: https://go-review.googlesource.com/c/go/+/160417
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: Ia42a4a658e4207cc1f036f2faeac011e71edad77
GitHub-Last-Rev: b384f81799fcd404f53647d8a3015487ea240c6f
GitHub-Pull-Request: golang/go#30012
Reviewed-on: https://go-review.googlesource.com/c/go/+/160436
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This keeps transparency of a wrapped image.Image even after it is encoded.
Fixes #30995
Change-Id: I1f7ac98b1741f83ed740f6eda6c36b7e9b16e5af
Reviewed-on: https://go-review.googlesource.com/c/go/+/177377
Reviewed-by: Hayato Kawakami <kawakami.ozone@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The PNG decode path attempts to handle paletted images that refer to
non-existent palette indicies. This PR fixes a corner case were images
that have exactly 255 palette colors and an IDAT chunk that references
palette index 255 produce an invalid image such that invoking At on
the pixel(s) in question causes an index out of range panic.
Fixes #31830
Change-Id: I34c44d9de5b9d76fe8c45c04e866fbc7f51f2a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/175397
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
They were added a very long time ago, as a convenience before Go had
struct literals. Today, it is better to use the zero-valued literal. For
example, the compiler cannot prove that ZP or ZR have not been modified.
Change-Id: I7469f1c751e91bf76fe1eab07b5772eccb5d6405
Reviewed-on: https://go-review.googlesource.com/c/go/+/171097
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Before -
$gotip build -gcflags="-d=ssa/check_bce/debug=1" fdct.go idct.go
./fdct.go:89:10: Found IsInBounds
./fdct.go:90:10: Found IsInBounds
./fdct.go:91:10: Found IsInBounds
./fdct.go:92:10: Found IsInBounds
./fdct.go:93:10: Found IsInBounds
./fdct.go:94:10: Found IsInBounds
./fdct.go:95:10: Found IsInBounds
./fdct.go:96:10: Found IsInBounds
./idct.go:77:9: Found IsInBounds
./idct.go:77:27: Found IsInBounds
./idct.go:77:45: Found IsInBounds
./idct.go:78:7: Found IsInBounds
./idct.go:78:25: Found IsInBounds
./idct.go:78:43: Found IsInBounds
./idct.go:78:61: Found IsInBounds
./idct.go:79:13: Found IsInBounds
./idct.go:92:13: Found IsInBounds
./idct.go:93:12: Found IsInBounds
./idct.go:94:12: Found IsInBounds
./idct.go:95:12: Found IsInBounds
./idct.go:97:12: Found IsInBounds
./idct.go:98:12: Found IsInBounds
./idct.go:99:12: Found IsInBounds
After -
$gotip build -gcflags="-d=ssa/check_bce/debug=1" fdct.go idct.go
./fdct.go:90:9: Found IsSliceInBounds
./idct.go:76:11: Found IsSliceInBounds
./idct.go:145:11: Found IsSliceInBounds
name old time/op new time/op delta
FDCT-4 1.85µs ± 2% 1.74µs ± 1% -5.95% (p=0.000 n=10+10)
IDCT-4 1.94µs ± 2% 1.89µs ± 1% -2.67% (p=0.000 n=10+9)
DecodeBaseline-4 1.45ms ± 2% 1.46ms ± 1% ~ (p=0.156 n=9+10)
DecodeProgressive-4 2.21ms ± 1% 2.21ms ± 1% ~ (p=0.796 n=10+10)
EncodeRGBA-4 24.9ms ± 1% 25.0ms ± 1% ~ (p=0.075 n=10+10)
EncodeYCbCr-4 26.1ms ± 1% 26.2ms ± 1% ~ (p=0.573 n=8+10)
name old speed new speed delta
DecodeBaseline-4 42.5MB/s ± 2% 42.4MB/s ± 1% ~ (p=0.162 n=9+10)
DecodeProgressive-4 27.9MB/s ± 1% 27.9MB/s ± 1% ~ (p=0.796 n=10+10)
EncodeRGBA-4 49.4MB/s ± 1% 49.1MB/s ± 1% ~ (p=0.066 n=10+10)
EncodeYCbCr-4 35.3MB/s ± 1% 35.2MB/s ± 1% ~ (p=0.586 n=8+10)
name old alloc/op new alloc/op delta
DecodeBaseline-4 63.0kB ± 0% 63.0kB ± 0% ~ (all equal)
DecodeProgressive-4 260kB ± 0% 260kB ± 0% ~ (all equal)
EncodeRGBA-4 4.40kB ± 0% 4.40kB ± 0% ~ (all equal)
EncodeYCbCr-4 4.40kB ± 0% 4.40kB ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
DecodeBaseline-4 5.00 ± 0% 5.00 ± 0% ~ (all equal)
DecodeProgressive-4 13.0 ± 0% 13.0 ± 0% ~ (all equal)
EncodeRGBA-4 4.00 ± 0% 4.00 ± 0% ~ (all equal)
EncodeYCbCr-4 4.00 ± 0% 4.00 ± 0% ~ (all equal)
Updates #24499
Change-Id: I6828d077b851817503a7c1a08235763f81bdadf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/167417
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Add a Fuzz function to package png, under the gofuzz build
tag. This function is based on the png/png.go code, from
github.com/dvyukov/go-fuzz-corpus, modified to use direct
comparison of image bounds rather than reflect.DeepEqual.
Updates #30979
Updates #19109
Change-Id: Idb86e7ded0c2d78e6cadbeda84c7b1f35b8c579c
Reviewed-on: https://go-review.googlesource.com/c/go/+/168558
Reviewed-by: thepudds <thepudds1460@gmail.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
|
|
When gif.Encode is given an "m image.Image" argument that isn't an
*image.Paletted, it creates a temporary *image.Paletted (called pm) that
is intended to be a copy of this image, only with fewer colors.
That creation process, and specifically the opts.Drawer.Draw call that
does the copy, incorrectly assumed that m.Bounds().Min is the zero point
(0, 0). This commit fixes that.
Fixes #30887
Change-Id: Ie03bddec359e2dcc52f18451049452105514e179
Reviewed-on: https://go-review.googlesource.com/c/go/+/168418
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Change-Id: I91378d5d5ecc1fc6741127a3924c631904da736b
Reviewed-on: https://go-review.googlesource.com/c/164199
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Change-Id: Id431969e42f0d9bd28bbf163d10378a6de2416f2
Reviewed-on: https://go-review.googlesource.com/c/141999
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Iskander Sharipov <iskander.sharipov@intel.com>
|
|
Use a subslice of the pixel data to give the compiler hints
for bounds checking. Only do this for image formats that
require 4 or more slice reads/writes.
See #27857 for discussion of small cap sizes.
name old time/op new time/op delta
At/rgba-8 18.8ns ± 2% 18.5ns ± 1% -1.49% (p=0.026 n=10+10)
At/rgba64-8 22.2ns ± 2% 21.1ns ± 3% -4.51% (p=0.000 n=10+10)
At/nrgba-8 18.8ns ± 2% 18.7ns ± 2% ~ (p=0.467 n=10+10)
At/nrgba64-8 21.9ns ± 2% 21.0ns ± 2% -4.15% (p=0.000 n=10+9)
At/alpha-8 14.3ns ± 1% 14.3ns ± 2% ~ (p=0.543 n=10+10)
At/alpha16-8 6.43ns ± 1% 6.47ns ± 1% ~ (p=0.053 n=10+10)
At/gray-8 14.4ns ± 2% 14.6ns ± 5% ~ (p=0.194 n=10+10)
At/gray16-8 6.52ns ± 1% 6.55ns ± 2% ~ (p=0.610 n=10+10)
At/paletted-8 4.17ns ± 1% 4.21ns ± 2% ~ (p=0.095 n=9+10)
Set/rgba-8 39.2ns ± 2% 40.1ns ± 4% +2.45% (p=0.007 n=10+10)
Set/rgba64-8 46.2ns ± 3% 43.3ns ± 3% -6.11% (p=0.000 n=10+10)
Set/nrgba-8 39.2ns ± 1% 39.7ns ± 5% ~ (p=0.407 n=10+10)
Set/nrgba64-8 45.6ns ± 3% 42.9ns ± 3% -5.83% (p=0.000 n=9+10)
Set/alpha-8 35.0ns ± 3% 34.1ns ± 2% -2.43% (p=0.017 n=10+10)
Set/alpha16-8 36.3ns ± 4% 35.8ns ± 5% ~ (p=0.254 n=10+10)
Set/gray-8 19.8ns ± 1% 19.7ns ± 0% -0.69% (p=0.002 n=8+6)
Set/gray16-8 36.0ns ± 1% 36.4ns ± 2% +1.08% (p=0.037 n=10+10)
Set/paletted-8 39.1ns ± 0% 39.6ns ± 1% +1.30% (p=0.000 n=10+10)
RGBAAt-8 3.72ns ± 1% 3.58ns ± 1% -3.76% (p=0.000 n=9+10)
RGBASetRGBA-8 4.35ns ± 1% 3.70ns ± 1% -14.92% (p=0.000 n=10+10)
RGBA64At-8 5.08ns ± 1% 3.69ns ± 1% -27.40% (p=0.000 n=9+9)
RGBA64SetRGBA64-8 6.65ns ± 2% 3.63ns ± 0% -45.35% (p=0.000 n=10+9)
NRGBAAt-8 3.72ns ± 1% 3.59ns ± 1% -3.55% (p=0.000 n=10+10)
NRGBASetNRGBA-8 4.05ns ± 0% 3.71ns ± 1% -8.57% (p=0.000 n=9+10)
NRGBA64At-8 4.99ns ± 1% 3.69ns ± 0% -26.07% (p=0.000 n=10+9)
NRGBA64SetNRGBA64-8 6.66ns ± 1% 3.64ns ± 1% -45.40% (p=0.000 n=10+10)
AlphaAt-8 1.44ns ± 1% 1.44ns ± 0% ~ (p=0.176 n=10+7)
AlphaSetAlpha-8 1.60ns ± 2% 1.56ns ± 0% -2.62% (p=0.000 n=10+6)
Alpha16At-8 2.87ns ± 1% 2.92ns ± 2% +1.67% (p=0.001 n=10+10)
AlphaSetAlpha16-8 3.26ns ± 1% 3.35ns ± 1% +2.68% (p=0.012 n=8+3)
Fixes #14884
Change-Id: Ia0383530596a550e1b1c7aafce5220e5e0935a53
Reviewed-on: https://go-review.googlesource.com/137495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Fixes #25884
Change-Id: I5478846ef78aecac32078ea8c3248db52f1bb534
Reviewed-on: https://go-review.googlesource.com/118755
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Use subslices with known length and cap to give bounds checking hints
to the compiler. Improves over the earlier pointer based optimizations
in https://go-review.googlesource.com/c/go/+/14093 for GlyphOver but
not for FillOver so the latter is left unchanged.
See #27857 for discussion of small caps used in subslices.
name old time/op new time/op delta
FillOver-8 607µs ± 1% 609µs ± 1% ~ (p=0.447 n=9+10)
FillSrc-8 23.0µs ± 1% 22.9µs ± 2% ~ (p=0.412 n=9+10)
CopyOver-8 647µs ± 0% 560µs ± 0% -13.43% (p=0.000 n=9+10)
CopySrc-8 19.3µs ± 1% 19.1µs ± 2% -0.66% (p=0.029 n=10+10)
NRGBAOver-8 697µs ± 1% 651µs ± 1% -6.64% (p=0.000 n=10+10)
NRGBASrc-8 405µs ± 1% 347µs ± 0% -14.23% (p=0.000 n=10+10)
YCbCr-8 432µs ± 2% 431µs ± 1% ~ (p=0.764 n=10+9)
Gray-8 164µs ± 1% 139µs ± 1% -15.44% (p=0.000 n=10+10)
CMYK-8 498µs ± 0% 461µs ± 0% -7.49% (p=0.000 n=10+9)
GlyphOver-8 220µs ± 0% 199µs ± 0% -9.52% (p=0.000 n=9+10)
RGBA-8 3.81ms ± 5% 3.79ms ± 5% ~ (p=0.549 n=9+10)
Paletted-8 1.73ms ± 0% 1.73ms ± 1% ~ (p=0.278 n=10+9)
GenericOver-8 11.0ms ± 2% 11.0ms ± 1% ~ (p=0.842 n=9+10)
GenericMaskOver-8 5.29ms ± 1% 5.30ms ± 0% ~ (p=0.182 n=9+10)
GenericSrc-8 4.24ms ± 1% 4.24ms ± 0% ~ (p=0.436 n=9+9)
GenericMaskSrc-8 7.89ms ± 1% 7.90ms ± 2% ~ (p=0.631 n=10+10)
Change-Id: I6fe1b21bb5e255826cbfdd2e73efd5858cd5557c
Reviewed-on: https://go-review.googlesource.com/136935
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
CL 136796 introduced benchmarks and refactored tests to use a
common list of test images. The tests now fail when run with
count > 2 since they rely on a fresh image each run.
Fix this by changing the list of test images to a list of test
image generator functions.
Change-Id: I5884c6bccba5e29bf84ee546fa501bc258379f42
Reviewed-on: https://go-review.googlesource.com/137295
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Bit packs image data when writing images with fewer than 16
colors in its palette. Reading of bit packed image data was
already implemented.
Fixes #19879
Change-Id: I0a06f9599a163931e20d3503fc3722e5101f0070
Reviewed-on: https://go-review.googlesource.com/134235
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Added in preparation for looking at some optimizations around bounds
checks.
BenchmarkAt/rgba-8 100000000 18.5 ns/op 4 B/op 1 allocs/op
BenchmarkAt/rgba64-8 100000000 22.9 ns/op 8 B/op 1 allocs/op
BenchmarkAt/nrgba-8 100000000 18.8 ns/op 4 B/op 1 allocs/op
BenchmarkAt/nrgba64-8 100000000 22.1 ns/op 8 B/op 1 allocs/op
BenchmarkAt/alpha-8 100000000 14.6 ns/op 1 B/op 1 allocs/op
BenchmarkAt/alpha16-8 200000000 6.46 ns/op 0 B/op 0 allocs/op
BenchmarkAt/gray-8 100000000 14.3 ns/op 1 B/op 1 allocs/op
BenchmarkAt/gray16-8 200000000 6.45 ns/op 0 B/op 0 allocs/op
BenchmarkAt/paletted-8 300000000 4.28 ns/op 0 B/op 0 allocs/op
BenchmarkSet/rgba-8 50000000 39.2 ns/op 8 B/op 2 allocs/op
BenchmarkSet/rgba64-8 30000000 45.8 ns/op 16 B/op 2 allocs/op
BenchmarkSet/nrgba-8 50000000 39.3 ns/op 8 B/op 2 allocs/op
BenchmarkSet/nrgba64-8 30000000 45.6 ns/op 16 B/op 2 allocs/op
BenchmarkSet/alpha-8 50000000 34.5 ns/op 2 B/op 2 allocs/op
BenchmarkSet/alpha16-8 50000000 34.9 ns/op 4 B/op 2 allocs/op
BenchmarkSet/gray-8 100000000 20.3 ns/op 1 B/op 1 allocs/op
BenchmarkSet/gray16-8 50000000 36.2 ns/op 4 B/op 2 allocs/op
BenchmarkSet/paletted-8 50000000 39.5 ns/op 1 B/op 1 allocs/op
BenchmarkRGBAAt-8 500000000 3.74 ns/op
BenchmarkRGBASetRGBA-8 300000000 4.33 ns/op
BenchmarkRGBA64At-8 300000000 5.06 ns/op
BenchmarkRGBA64SetRGBA64-8 200000000 6.61 ns/op
BenchmarkNRGBAAt-8 500000000 3.69 ns/op
BenchmarkNRGBASetNRGBA-8 300000000 4.06 ns/op
BenchmarkNRGBA64At-8 300000000 4.98 ns/op
BenchmarkNRGBA64SetNRGBA64-8 200000000 6.62 ns/op
BenchmarkAlphaAt-8 2000000000 1.43 ns/op
BenchmarkAlphaSetAlpha-8 2000000000 1.55 ns/op
BenchmarkAlpha16At-8 1000000000 2.87 ns/op
BenchmarkAlphaSetAlpha16-8 500000000 3.27 ns/op
BenchmarkGrayAt-8 2000000000 1.43 ns/op
BenchmarkGraySetGray-8 2000000000 1.55 ns/op
BenchmarkGray16At-8 1000000000 2.87 ns/op
BenchmarkGraySetGray16-8 500000000 3.14 ns/op
Updates #14884
Change-Id: I349fb214ee75f13ecbc62ac22a40e3b337648f60
Reviewed-on: https://go-review.googlesource.com/136796
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Removes a redundant err check and replaces some returns in a testing
loop with continue to prevent skipping unrelated test cases when
a failure is encountered.
Change-Id: Ic1a560751b95bb0ef8dfa957e057e0fa0c2b281d
Reviewed-on: https://go-review.googlesource.com/134236
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
|
|
Use the binary.{Big,Little}Endian integer encoding methods rather than
variations found in local implementations. The functions in
the binary package have been tested to ensure they inline correctly and
don't add unnecessary bounds checking.
Change-Id: Ie10111ca6edb7c11e8e5e21c58a5748ae99b7f87
Reviewed-on: https://go-review.googlesource.com/134375
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
|
|
Change-Id: Ie801fe6a2883d79229ee2955e26948c1b4964802
Reviewed-on: https://go-review.googlesource.com/122496
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Each URL was manually verified to ensure it did not serve up incorrect
content.
Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df
Reviewed-on: https://go-review.googlesource.com/115798
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
This is a simple but everyday use case in image libraries. Currently,
there is one example in this library and it is lengthy and involved.
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Change-Id: Idca527d97c095af88755446e1548fa2b8ace7eb0
GitHub-Last-Rev: f5743c8ef337a8b7a5126db21d784593f4f53c8a
GitHub-Pull-Request: golang/go#25616
Reviewed-on: https://go-review.googlesource.com/114939
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
I found files to change with this command:
git grep 'DO NOT EDIT' | grep -v 'Code generated .* DO NOT'
There are more files that match that grep, but I do not intend on fixing
them.
Change-Id: I4b474f1c29ca3135560d414785b0dbe0d1a4e52c
GitHub-Last-Rev: 65804b02634abd85bf113788b38354d48801241f
GitHub-Pull-Request: golang/go#24334
Reviewed-on: https://go-review.googlesource.com/99955
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
GitHub-Last-Rev: 468df242d07419c228656985702325aa78952d99
GitHub-Pull-Request: golang/go#23935
Change-Id: If751ce3ffa3a4d5e00a3138211383d12cb6b23fc
Reviewed-on: https://go-review.googlesource.com/95577
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
The Netscape looping application extension encodes how many
times the animation should restart, and if it's present
there is no way to signal that a GIF should play only once.
Use LoopCount=-1 to signal when a decoded GIF had no looping
extension, and update the encoder to omit that extension
block when LoopCount=-1.
Fixes #15768
GitHub-Last-Rev: 249744f0e28ef8907aa876070a102cb5493f5084
GitHub-Pull-Request: golang/go#23761
Change-Id: Ic915268505bf12bdad690b59148983a7d78d693b
Reviewed-on: https://go-review.googlesource.com/93076
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This reverts commit 08f19bbde1b01227fdc2fa2d326e4029bb74dd96.
Reason for revert:
The changed transformation takes effect on a larger set
of code snippets than expected.
For example, this:
func foo() {
// Comment
bar()
}
becomes:
func foo() {
// Comment
bar()
}
This is an unintended consequence.
Change-Id: Ifca88d6267dab8a8170791f7205124712bf8ace8
Reviewed-on: https://go-review.googlesource.com/81335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The go repository contains a mix of github.com/golang/go/issues/xxxxx
and golang.org/issues/xxxxx URLs for references to issues in the issue
tracker. We should use one for consistency, and golang.org is preferred
in case the project moves the issue tracker in the future.
This reasoning is taken from a comment Sam Whited left on a CL I
recently opened: https://go-review.googlesource.com/c/go/+/73890.
In that CL I referenced an issue using its github.com URL, because other
tests in the file I was changing contained references to issues using
their github.com URL. Sam Whited left a comment on the CL stating I
should change it to the golang.org URL.
If new code is intended to reference issues via golang.org and not
github.com, existing code should be updated so that precedence exists
for contributors who are looking at the existing code as a guide for the
code they should write.
Change-Id: I3b9053fe38a1c56fc101a8b7fd7b8f310ba29724
Reviewed-on: https://go-review.googlesource.com/75673
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
To improve readability when exported fields are removed,
forbid the printer from emitting an empty line before the first comment
in a const, var, or type block.
Also, when printing the "Has filtered or unexported fields." message,
add an empty line before it to separate the message from the struct
or interfact contents.
Before the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
After the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
Fixes #18264
Change-Id: I9fe17ca39cf92fcdfea55064bd2eaa784ce48c88
Reviewed-on: https://go-review.googlesource.com/71990
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Function sqDiff is called multiple times in the hot path (x, y loops) of
drawPaletted from the image/draw package; number of sqDiff calls is
between 4×width×height and 4×width×height×len(palette) for each
drawPaletted call.
Simplify this function by removing arguments comparison and relying
instead on signed to unsigned integer conversion rules and properties of
unsigned integer values operations guaranteed by the spec:
> For unsigned integer values, the operations +, -, *, and << are
> computed modulo 2n, where n is the bit width of the unsigned integer's
> type. Loosely speaking, these unsigned integer operations discard high
> bits upon overflow, and programs may rely on ``wrap around''.
image/gif package benchmark that depends on the code updated shows
throughput improvements:
name old time/op new time/op delta
QuantizedEncode-4 788ms ± 2% 468ms ± 9% -40.58% (p=0.000 n=9+10)
name old speed new speed delta
QuantizedEncode-4 1.56MB/s ± 2% 2.63MB/s ± 8% +68.47% (p=0.000 n=9+10)
Closes #22375.
Change-Id: Ic9a540e39ceb21e7741d308af1cfbe61b4ac347b
Reviewed-on: https://go-review.googlesource.com/72373
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
drawPaletted has to discover R,G,B,A color values of each source image
pixel in a given rectangle. Doing that by calling image.Image.At()
method returning color.Color interface is quite taxing allocation-wise
since interface values go through heap. Introduce special cases for some
concrete source types by fetching color values using type-specific
methods.
name old time/op new time/op delta
Paletted-4 7.62ms ± 4% 3.72ms ± 3% -51.20% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
Paletted-4 480kB ± 0% 0kB ± 0% -99.99% (p=0.000 n=4+5)
name old allocs/op new allocs/op delta
Paletted-4 120k ± 0% 0k ± 0% -100.00% (p=0.008 n=5+5)
Updates #15759.
Change-Id: I0ce1770ff600ac80599541aaad4c2c826855c8fb
Reviewed-on: https://go-review.googlesource.com/72370
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
decoder.decode() was defering close of lzw.decoders created for each
frame in a loop, thus increasing heap usage (referenced object + defered
function) until decode() returns. Memory increased proportionally to the
number of frames. Fix this by moving the sImageDescriptor case block
into its own method.
Fixes #22237
Change-Id: I819617ea7e539e13c04bc11112f339645391ddb9
Reviewed-on: https://go-review.googlesource.com/70370
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
Previously, the code would only check (w*h), not (w*h*bpp).
Fixes #22304
Change-Id: Iaca26d916fe4b894d460448c416b1e0b9fd68e44
Reviewed-on: https://go-review.googlesource.com/72350
Reviewed-by: Rob Pike <r@golang.org>
|
|
golang.org/cl/37258 was committed to fix issue #16146.
This patch seemed intent to allow at most one dangling byte. But, as
implemented, many more bytes may actually slip through. This is because
the LZW layer creates a bufio.Reader which will itself consume data
beyond the end of the LZW stream, and this isn't accounted for anywhere.
This change means to avoid the allocation of the bufio.Reader by making
blockReader implement io.ByteReader. Further, it adds a close() method
which detects extra data in the block sequence. To avoid any
regressions with poorly encoded GIFs which may have worked accidentally,
there are no restrictions on how many extra bytes may exist in the final
full sub-block that contained LZW data. If the end of the LZW stream
happened to align with the end of a sub-block, at most one more
sub-block with a length of 1 byte may exist before the block terminator.
This change aims to be at least as performant as the prior
implementation. But the primary gain is avoiding the allocation of a
bufio.Reader per frame:
name old time/op new time/op delta
Decode-8 276µs ± 0% 275µs ± 2% ~ (p=0.690 n=5+5)
name old speed new speed delta
Decode-8 55.9MB/s ± 0% 56.3MB/s ± 2% ~ (p=0.690 n=5+5)
name old alloc/op new alloc/op delta
Decode-8 49.2kB ± 0% 44.8kB ± 0% -9.10% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Decode-8 269 ± 0% 267 ± 0% -0.74% (p=0.008 n=5+5)
Change-Id: Iec4f9b895561ad52266313fbc73ec82c070c3349
Reviewed-on: https://go-review.googlesource.com/68350
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
The indexed bitmap of a frame is encoded into a GIF by first LZW
compression, and then packaged by a simple block mechanism. Each block
of up-to-256 bytes starts with one byte, which indicates the size of the
block (0x01-0xff). The sequence of blocks is terminated by a 0x00.
While the format supports it, there is no good reason why any particular
image should be anything but a sequence of 255-byte blocks with one last
block less than 255-bytes.
The old blockWriter implementation would not buffer between Write()s,
meaning if the lzw Writer needs to flush more than one chunk of data via
a Write, multiple short blocks might exist in the middle of a stream.
Separate but related, the old implementation also forces lzw.NewWriter
to allocate a bufio.Writer because the blockWriter is not an
io.ByteWriter itself. But, even though it doesn't effectively buffer
data between Writes, it does make extra copies of sub-blocks during the
course of writing them to the GIF's writer.
Now, the blockWriter shall continue to use the encoder's [256]byte buf,
but use it to effectively buffer a series of WriteByte calls from the
lzw Writer. Once a WriteByte fills the buffer, the staged block is
Write()n to the underlying GIF writer. After the lzw Writer is Closed,
the blockWriter should also be closed, which will flush any remaining
block along with the block terminator.
BenchmarkEncode indicates slight improvements:
name old time/op new time/op delta
Encode-8 7.71ms ± 0% 7.38ms ± 0% -4.27% (p=0.008 n=5+5)
name old speed new speed delta
Encode-8 159MB/s ± 0% 167MB/s ± 0% +4.46% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
Encode-8 84.1kB ± 0% 80.0kB ± 0% -4.94% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Encode-8 9.00 ± 0% 7.00 ± 0% -22.22% (p=0.008 n=5+5)
Change-Id: I9eb9367d41d7c3d4d7f0adc9b720fc24fb50006a
Reviewed-on: https://go-review.googlesource.com/68351
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
The GIF format allows for an image to contain a global color table which
might be used for some or every frame in an animated GIF. This palette
contains 24-bit opaque RGB values. An individual frame may use the
global palette and enable transparency by picking one number to be
transparent, instead of the color value in the palette.
image/gif decodes a GIF, which contains an []*image.Paletted that holds
each frame. When decoded, if a frame has a transparent color and uses
the global palette, a copy of the global []color.Color is made, and the
transparency color index is replaced with color.RGBA{}.
When encoding a GIF, each frame's palette is encoded to the form it
might exist in a GIF, up to 768 bytes "RGBRGBRGBRGB...". If a frame's
encoded palette is equal to the encoded global color table, the frame
will be encoded with the flag set to use the global color table,
otherwise the frame's palette will be included.
So, if the color in the global color table that matches the transparent
index of one frame wasn't black (and it frequently is not), reencoding a
GIF will likely result in a larger file because each frame's palette
will have to be encoded inline.
This commit takes a frame's transparent color index into account when
comparing an individual image.Paletted's encoded color table to the
global color table.
Fixes #22137
Change-Id: I5460021da6e4d7ce19198d5f94a8ce714815bc08
Reviewed-on: https://go-review.googlesource.com/68313
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Decode decodes entire GIF image and returns the first frame as an
image.Image. There's no need for it to keep every decoded frame in
memory except for the one it returns.
Fixes #22199
Change-Id: I76b4bd31608ebc76a1a3df02e85c20eb80df7877
Reviewed-on: https://go-review.googlesource.com/69890
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Also add some b.ReportAllocs calls to other image codec benchmarks.
Change-Id: I0f055dc76bffb66329c621a5f1ccd239f0cdd30b
Reviewed-on: https://go-review.googlesource.com/68390
Reviewed-by: Jed Denlea <jed@fastly.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
a -> an
Change-Id: I7362bdc199e83073a712be657f5d9ba16df3077e
Reviewed-on: https://go-review.googlesource.com/63850
Reviewed-by: Rob Pike <r@golang.org>
|
