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

gofmt -w src misc

Fixes #1414.

R=rsc, r
CC=golang-dev
https://golang.org/cl/4456054

When traversing parameter lists (e.g. for type checking), we want the
invariant that all identifers have associated objects (even _ idents),
so that we can associate a type with each object.

R=rsc
CC=golang-dev
https://golang.org/cl/4490042

Had bit test wrong on transparency; no excuses.

R=nigeltao
CC=golang-dev
https://golang.org/cl/4526044

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

Fixes #1786.

R=gri, adg
CC=golang-dev
https://golang.org/cl/4517043

Fixes #1788.

R=rsc, adg
CC=golang-dev
https://golang.org/cl/4519042

R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/4471046

This change fixes generation of "shadow" variables for bool parameters.
Before the change, it was naming all bool variables with the same name of _p0.
Now it calls them _p0, _p1, ... So the code could compile.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4479047

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

instead of returning an error.

For example, http://www.w3.org/Graphics/GIF/spec-gif89a.txt
explicitly says that GIF encoders can use a full table as is,
without needing to send a clear code.

R=r, dsymonds, nigeltao_gnome, r2
CC=golang-dev
https://golang.org/cl/4518041

Fixes #1785.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4496042

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4492043

This means that the -x flag can work, which could enable
support for other languages (e.g. objective-C).

R=iant, rsc
CC=golang-dev
https://golang.org/cl/4476049

R=adg, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4491041

R=rsc
CC=golang-dev
https://golang.org/cl/4396050

R=adg
CC=golang-dev
https://golang.org/cl/4485046

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4477046

The verified chains are the chains that were actually verified.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4462046

The SPKI will probably be used for identifying public keys in future
HSTS specs.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4485044

R=nigeltao, r
CC=golang-dev
https://golang.org/cl/4471045

R=r
CC=golang-dev
https://golang.org/cl/4462043

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

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4436074

On my laptop, I had an 800x600 jpeg and an 800x600 png (with
transparency). I timed how long it took to draw each image onto an
equivalently sized, zeroed RGBA image.

Previously, the jpeg took 75ms and the png took 70ms, going through
the medium-fast path, i.e. func drawRGBA in draw.go.

After this CL, the jpeg took 14ms, and the png took 21ms with the
Over operator and 12ms with the Src operator.

It's only a rough estimate basd on one image file, but it should
give an idea of the order of magnitude of improvement.

R=rsc, r
CC=adg, golang-dev
https://golang.org/cl/4468044

R=adg
CC=golang-dev
https://golang.org/cl/4468043

R=adg
CC=golang-dev
https://golang.org/cl/4471041

R=rsc
CC=golang-dev
https://golang.org/cl/4463042

R=golang-dev, bradfitzwork
CC=golang-dev
https://golang.org/cl/4466041

The file is called gotest.exe now.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4444090

Should prevent failures on slow machines, such as:
http://godashboard.appspot.com/log/47b5cae591b7ad8908704e327f3b9b41945d7d5fecfc0c8c945d5545ece1a813

Verified the change (on a fast machine) by removing the
existing sleep, in which case the race happens ~50% of the
time with GOMAXPROCS > 1, but recovers gracefully with
retries.

R=rsc
CC=golang-dev
https://golang.org/cl/4441089

R=r
CC=golang-dev
https://golang.org/cl/4431088

R=r, r2
CC=golang-dev
https://golang.org/cl/4435083

R=golang-dev, r, adg, r2
CC=golang-dev
https://golang.org/cl/4457049

R=iant, iant2
CC=golang-dev
https://golang.org/cl/4453058

Note that if you are working on the upcoming release
branch you have to point your extension path to a
copy of lib/codereview/codereview.py that won't change
as the repository flips between release-branch and default branch.
This warning should only apply to this one branch and only to rsc,
but you never know.

R=adg
CC=golang-dev
https://golang.org/cl/4446076

Fixes #1748.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4444087

Fixes #1350

R=rsc, bradfitzwork
CC=golang-dev
https://golang.org/cl/4432089

Fixes #1771.

R=adg, rsc1
CC=golang-dev
https://golang.org/cl/4437089