Change-Id: I9582aff7ca141a8aead5692af74b9c708b1700cc
Reviewed-on: https://go-review.googlesource.com/5020Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Idd66f9c3c9eaa4ff1f950fb90e4800dc625dec08
Reviewed-on: https://go-review.googlesource.com/4916Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

https://go-review.googlesource.com/#/c/1876/ introduced a new
TestClipWithNilMP test, along with a code change that fixed a panic,
but the existing TestClip test already contained almost enough machinery
to cover that bug.

There is a small code change in this CL, but it is a no-op: (*x).y is
equivalent to x.y for a pointer-typed x, but the latter is cleaner.

Change-Id: I79cf6952a4999bc4b91f0a8ec500acb108106e56
Reviewed-on: https://go-review.googlesource.com/2304Reviewed-by: Dave Cheney <dave@cheney.net>

Fixes #9177

Change-Id: I1c7e57f0f0a9b00fb3ddc7fa4844ac53ea6df46f
Reviewed-on: https://go-review.googlesource.com/1876Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.

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

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

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

Originally published on The Go Programming Language Blog, September 29, 2011.

http://blog.golang.org/2011/09/go-imagedraw-package.html

Update #2547.

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

instead of the origin.

This makes YCbCr match the other image types (e.g. RGBA, Gray) in
that an image's bounds is not restricted to the positive quadrant.

Also optimize the YCbCr draw code by hoisting some computation
outside of the loop.

benchmark              old ns/op    new ns/op    delta
draw.BenchmarkYCbCr      2544418      2373558   -6.72%

Like https://golang.org/cl/4681044/ I don't think a gofix is
feasible. People will have to make manual changes. On the other hand,
directly manipulating YCbCr images is relatively rare, compared to
RGBA images, and if other code just uses the jpeg and draw packages
instead of messing directly with a YCbCr's []byte representations,
then things should just continue to work.

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

image/draw benchmarks show <1% change for the fast paths.
The slow paths got worse by 1-4%, but they're the slow paths.
I don't care so much about them, and presumably compiler improvements
could claw it back.

IIUC 6g's inlining is enabled by default now.

benchmark                        old ns/op    new ns/op    delta
draw.BenchmarkFillOver             2988384      2999624   +0.38%
draw.BenchmarkFillSrc               153141       153262   +0.08%
draw.BenchmarkCopyOver             2155756      2170831   +0.70%
draw.BenchmarkCopySrc                72591        72646   +0.08%
draw.BenchmarkNRGBAOver            2487372      2491576   +0.17%
draw.BenchmarkNRGBASrc             1361306      1409180   +3.52%
draw.BenchmarkYCbCr                2540712      2562359   +0.85%
draw.BenchmarkGlyphOver            1004879      1023308   +1.83%
draw.BenchmarkRGBA                 8746670      8844455   +1.12%
draw.BenchmarkGenericOver         31860960     32512960   +2.05%
draw.BenchmarkGenericMaskOver     16369060     16435720   +0.41%
draw.BenchmarkGenericSrc          13128540     13127810   -0.01%
draw.BenchmarkGenericMaskSrc      30059300     28883210   -3.91%

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

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

The spin-off renames some types. The new names are simply better:
image.Color              -> color.Color
image.ColorModel         -> color.Model
image.ColorModelFunc     -> color.ModelFunc
image.PalettedColorModel -> color.Palette
image.RGBAColor          -> color.RGBA
image.RGBAColorModel     -> color.RGBAModel
image.RGBA64Color        -> color.RGBA64
image.RGBA64ColorModel   -> color.RGBA64Model
(similarly for NRGBAColor, GrayColorModel, etc)

The image.ColorImage type stays in the image package, but is renamed:
image.ColorImage -> image.Uniform

The image.Image implementations (image.RGBA, image.RGBA64, image.NRGBA,
image.Alpha, etc) do not change their name, and gain a nice symmetry:
an image.RGBA is an image of color.RGBA, etc.

The image.Black, image.Opaque uniform images remain unchanged (although
their type is renamed from image.ColorImage to image.Uniform). The
corresponding color types (color.Black, color.Opaque, etc) are new.

Nothing in the image/ycbcr is renamed yet. The ycbcr.YCbCrColor and
ycbcr.YCbCrImage types will eventually migrate to color.YCbCr and
image.YCbCr, but that will be a separate CL.

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

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

DrawMask already returns early if r.Empty().

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

There are no behavioral changes, only some copy-and-pastes.

Before, drawFillOver was next to drawCopyOver.

After, drawFillOver is next to drawFillSrc, which is more similar to
drawFillOver than drawCopyOver is.

Similarly, drawCopyOver is now next to drawCopySrc, etc.

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

Some benchmark numbers below. The image/draw fast-paths show dramatic
improvement, the generic slow-paths show a smaller slow-down.

BEFORE
png.BenchmarkEncodePaletted      200       8203800 ns/op      37.45 MB/s
png.BenchmarkEncodeRGBOpaque         100      26940440 ns/op      45.61 MB/s
png.BenchmarkEncodeRGBA       20      73821000 ns/op      16.65 MB/s
jpeg.BenchmarkEncodeRGBOpaque         50      35598640 ns/op      34.52 MB/s
draw.BenchmarkFillOver	     500	   4024226 ns/op
draw.BenchmarkFillSrc	   10000	    152736 ns/op
draw.BenchmarkCopyOver	     500	   3452824 ns/op
draw.BenchmarkCopySrc	   50000	     73218 ns/op
draw.BenchmarkNRGBAOver	     500	   3941234 ns/op
draw.BenchmarkNRGBASrc	    1000	   2484400 ns/op
draw.BenchmarkYCbCr	    1000	   2609005 ns/op
draw.BenchmarkGlyphOver	    2000	   1169575 ns/op
draw.BenchmarkRGBA	     200	   9031390 ns/op
draw.BenchmarkGenericOver	      50	  34636620 ns/op
draw.BenchmarkGenericMaskOver	     100	  16561150 ns/op
draw.BenchmarkGenericSrc	     100	  13873760 ns/op
draw.BenchmarkGenericMaskSrc	     100	  25198860 ns/op

AFTER
png.BenchmarkEncodePaletted      200       8206600 ns/op      37.43 MB/s
png.BenchmarkEncodeRGBOpaque         100      26129530 ns/op      47.03 MB/s
png.BenchmarkEncodeRGBA       20      75776750 ns/op      16.22 MB/s
jpeg.BenchmarkEncodeRGBOpaque         50      37192940 ns/op      33.04 MB/s
draw.BenchmarkFillOver	     500	   3008134 ns/op
draw.BenchmarkFillSrc	   10000	    154214 ns/op
draw.BenchmarkCopyOver	    1000	   2169988 ns/op
draw.BenchmarkCopySrc	   50000	     73095 ns/op
draw.BenchmarkNRGBAOver	    1000	   2491079 ns/op
draw.BenchmarkNRGBASrc	    2000	   1361244 ns/op
draw.BenchmarkYCbCr	    1000	   2554269 ns/op
draw.BenchmarkGlyphOver	    2000	   1042225 ns/op
draw.BenchmarkRGBA	     100	  10233340 ns/op
draw.BenchmarkGenericOver	      50	  38421560 ns/op
draw.BenchmarkGenericMaskOver	     100	  17521190 ns/op
draw.BenchmarkGenericSrc	     100	  16351200 ns/op
draw.BenchmarkGenericMaskSrc	     100	  26538190 ns/op

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

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

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

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

image: add Rectangle.ContainsRectangle method.

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

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

It was only used by exp/4s, and even if it is general purpose, I think
it belongs in a graphics library atop exp/draw, not in exp/draw itself.

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

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

Make ColorImage methods' receiver type be a pointer.

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

R=rsc, r2
CC=golang-dev
https://golang.org/cl/2248046

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

The min is typically zero, which is why this hasn't bitten us yet.

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

image: introduce Intersect and Union rectangle methods.

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

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

image: introduce Transparent and Opaque.

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

stride and rect.

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

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

Make dpix variable names consistent.

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

R=gri
CC=golang-dev
https://golang.org/cl/1548042

Time (us) to draw a 200x200 src onto an image.RGBA dst with the Over
operator. Each case was measured three separate times, and the sorted
times are reported.

Fill case (where src is an image.ColorImage):
Before:
7438, 7511, 7526
After:
3073, 3087, 3102

Copy case (where src is an image.RGBA):
Before:
9506, 9510, 9563
After:
5262, 5300, 5344

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

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

Time to draw.Draw a 200x200 image fell from 18.4ms (and 1 malloc) to
5.6ms (and 0 mallocs). It's still relatively slow since it assumes
nothing about the src or mask images, but it does remove the malloc.
There are existing faster, more specialized paths for copies, fills
and image glyph masks.

Also added a "compare to a slow but obviously correct implementation"
check to draw_test.go.

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

Timings (as for change 1122043) go from 49ms to 48ms ish. It's
mostly lost in the noise, but it probably doesn't hurt.

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

To draw.Draw a 32x32 image.Alpha 10000 times,
Before: 633ms with 10000 mallocs
After: 49ms with 0 mallocs

These times are just blitting an image.Alpha, and do not include
rasterizing a glyph's vector contours to an image.Alpha.

The "generic" test case in draw_test.go tests this fast path.

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