of the origin.
image/png and image/jpeg benchmarks show no significant changes.
The image/draw changes suggest to me that making a gofix for this is not
feasible. People are just going to have to make manual fixes.
R=r
CC=golang-dev
https://golang.org/cl/4681044
at (0, 0).
Also refactor the test to use the SubImage method rather than monkeying
with an image's Pix and Rect fields.
R=r
CC=golang-dev
https://golang.org/cl/4678045
This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
The TIFF spec says that a baseline TIFF reader must gracefully terminate
when the image has a SampleFormat tag which it does not support.
For baseline compatibility, only SampleFormat=1 (the default) is needed.
Images with other sample formats (e.g. floating-point color values)
are very rare in practice.
R=nigeltao
CC=golang-dev
https://golang.org/cl/4515073
writing the idct result directly to the image buffer instead of
storing it in an intermediate d.blocks field.
Writing to d.blocks was necessary when decoding to an image.RGBA image,
but now that we decode to a ycbcr.YCbCr we can write each component
directly to the image buffer.
Crude "time ./6.out" scores to decode a specific 2592x1944 JPEG 20
times show a 16% speed-up:
BEFORE
user 0m10.410s
user 0m10.400s
user 0m10.480s
user 0m10.480s
user 0m10.460s
AFTER
user 0m9.050s
user 0m9.050s
user 0m9.050s
user 0m9.070s
user 0m9.020s
R=r
CC=golang-dev
https://golang.org/cl/4523052
At least, as I understand it. The spec is unclear about what happens
with a local color map.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4515045
It's incomplete but sufficient to decode 8-bit GIFs without interlacing
or transparency. More to come.
I'll put in more tests as the feature set grows.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4522041
The current iteration can decode 8-bit images in
grayscale, paletted, RGB, RGBA and NRGBA mode. LZW compression
is implemented but does not work on my test images.
Deflate (i.e. zlib) compression with or without a horizontal
predictor is supported.
R=nigeltao, nigeltao_gnome
CC=golang-dev, mpl
https://golang.org/cl/4240051
Encoder now writes tRNS chunk for non-opaque paletted images.
CL includes new test images (basn3a08-trns.[ps]ng).
R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432078
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
R=r, r2, nigeltao
CC=golang-dev
https://golang.org/cl/4433088
We replace the current Open with:
OpenFile(name, flag, perm) // same as old Open
Open(name) // same as old Open(name, O_RDONLY, 0)
Create(name) // same as old Open(name, O_RDWR|O_TRUNC|O_CREAT, 0666)
This CL includes a gofix module and full code updates: all.bash passes.
(There may be a few comments I missed.)
The interesting packages are:
gofix
os
Everything else is automatically generated except for hand tweaks to:
src/pkg/io/ioutil/ioutil.go
src/pkg/io/ioutil/tempfile.go
src/pkg/crypto/tls/generate_cert.go
src/cmd/goyacc/goyacc.go
src/cmd/goyacc/units.y
R=golang-dev, bradfitzwork, rsc, r2
CC=golang-dev
https://golang.org/cl/4357052
The test image was converted from doc/video-001.png using the
convert command line tool (ImageMagick 6.5.7-8) at -quality 100.
R=r, nigeltao_gnome
CC=golang-dev
https://golang.org/cl/4259047
Rect types.
The actual image representation is unchanged. A future change will
replace the {[][]color} with {[]color, stride int, r Rectangle} and
possibly a clip region.
The draw.Color, draw.Point and draw.Rect types will be removed in a
future change. Trying to do it in this one polluted the diff with
trivia.
R=r, rsc
CC=golang-dev
https://golang.org/cl/1918047
x.go:13: cannot use t (type T) as type Reader in assignment:
T does not implement Reader (Read method requires pointer receiver)
x.go:19: cannot use q (type Q) as type Reader in assignment:
Q does not implement Reader (missing Read method)
have read()
want Read()
x.go:22: cannot use z (type int) as type Reader in assignment:
int does not implement Reader (missing Read method)
x.go:24: too many arguments to conversion to complex: complex(1, 3)
R=ken2
CC=golang-dev
https://golang.org/cl/1736041
This is not a complete JPEG implementation (e.g. it does not handle
progressive JPEGs or restart markers), but I was able to take a photo
with my phone, and view the resultant JPEG in pure Go.
The decoder is simple, but slow. The Huffman decoder in particular
should be easily improvable, but optimization is left to future
changelists. Being able to inline functions in the inner loop should
also help performance.
The output is not pixel-for-pixel identical to libjpeg, although
identical behavior isn't necessarily a goal, since JPEG is a lossy
codec. There are at least two reasons for the discrepancy.
First, the inverse DCT algorithm used is the same as Plan9's
src/cmd/jpg, which has different rounding errors from libjpeg's
default IDCT implementation. Note that libjpeg actually has three
different IDCT implementations: one floating point, and two fixed
point. Out of those four, Plan9's seemed the simplest to understand,
partly because it has no #ifdef's or C macros.
Second, for 4:2:2 or 4:2:0 chroma sampling, this implementation does
nearest neighbor upsampling, compared to libjpeg's triangle filter
(e.g. see h2v1_fancy_upsample in jdsample.c).
The difference from the first reason is typically zero, but sometimes
1 (out of 256) in YCbCr space, or double that in RGB space. The
difference from the second reason can be as large as 8/256 in YCbCr
space, in regions of steep chroma gradients. Informal eyeballing
suggests that the net difference is typically imperceptible, though.
R=r
CC=golang-dev, rsc
https://golang.org/cl/164056
parsing and printing to new syntax.
Use -oldparser to parse the old syntax,
use -oldprinter to print the old syntax.
2) Change default gofmt formatting settings
to use tabs for indentation only and to use
spaces for alignment. This will make the code
alignment insensitive to an editor's tabwidth.
Use -spaces=false to use tabs for alignment.
3) Manually changed src/exp/parser/parser_test.go
so that it doesn't try to parse the parser's
source files using the old syntax (they have
new syntax now).
4) gofmt -w src misc test/bench
3rd set of files.
R=rsc
CC=golang-dev
https://golang.org/cl/180048
the bash scripts and makefiles for building go didn't take into account
the fact $GOROOT / $GOBIN could both be directories containing whitespaces,
and was not possible to build it in such a situation.
this commit adjusts the various makefiles/scripts to make it aware of that
possibility, and now it builds successfully when using a path with whitespaces
as well.
Fixes#115.
R=rsc, dsymonds1
https://golang.org/cl/157067
- enabled for function declarations (not just function literals)
- applied gofmt -w $GOROOT/src
(look for instance at src/pkg/debug/elf/elf.go)
R=r, rsc
CC=go-dev
http://go/go-review/1026006
