Each span of unindented non-blank lines is converted into a
single paragraph. This isn't desired here. Indent the matrix,
so that it's converted into a <pre> block. That also prevents
the previous line from being interpreted as a heading.
Reference: https://godoc.org/go/doc#ToHTMLFixesgolang/go#28683
Change-Id: Ibc5488d5cc66fe3a5f2bbe2fe23628dd08276037
Reviewed-on: https://go-review.googlesource.com/c/148573
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It's more args (in terms of bytes), but fewer allocations (Transformer
is an interface). Either way, it's not really that big of a deal, but
the value instead of the pointer seems conceptually more correct.
Change-Id: Ibea76da17cbda0d9633110fd56044b4e2c690e81
Reviewed-on: https://go-review.googlesource.com/12669
Reviewed-by: Rob Pike <r@golang.org>
This change only adds the fields, more or less. Follow-up changes will
actually honor the masks.
Change-Id: I81411dc1aac4b3c846dcdf13e2cb0b5cd60fb2b4
Reviewed-on: https://go-review.googlesource.com/8902
Reviewed-by: Rob Pike <r@golang.org>
The two Ops are equivalent, but Src is faster.
Change-Id: I2c73a13755047c224c71fb5af786875f02681de9
Reviewed-on: https://go-review.googlesource.com/8640
Reviewed-by: Rob Pike <r@golang.org>
This change only *prepares* the codegen to handle multiple Ops. The
actual generated code still only supports one Op (Src) and not the other
(Over). A follow-up change will add Over.
This Op switch (an eventual x2 multiplier in the amount of code
generated) should be the last of the codegen LoC multipliers. The dst
and src mask options will be implemented in the slow path fallback.
Change-Id: Iecbcc6fad063e2aac36d78d5380c0a0947c709df
Reviewed-on: https://go-review.googlesource.com/8488
Reviewed-by: Rob Pike <r@golang.org>
benchmark old ns/op new ns/op delta
BenchmarkScaleBLLargeDown 257715146 260286012 +1.00%
BenchmarkScaleCRLargeDown 426797448 430078734 +0.77%
BenchmarkScaleBLDown 4449939 4222542 -5.11%
BenchmarkScaleCRDown 8160446 8010056 -1.84%
BenchmarkScaleBLUp 22290312 21044122 -5.59%
BenchmarkScaleCRUp 33010722 32021468 -3.00%
BenchmarkScaleCRSrcGray 13307961 13020192 -2.16%
BenchmarkScaleCRSrcNRGBA 40567431 40801939 +0.58%
BenchmarkScaleCRSrcRGBA 39892971 40240558 +0.87%
BenchmarkScaleCRSrcYCbCr 59020222 59686699 +1.13%
benchmark old allocs new allocs delta
BenchmarkScaleBLLargeDown 1 1 +0.00%
BenchmarkScaleCRLargeDown 1 2 +100.00%
BenchmarkScaleBLDown 1 0 -100.00%
BenchmarkScaleCRDown 1 0 -100.00%
BenchmarkScaleBLUp 1 0 -100.00%
BenchmarkScaleCRUp 1 0 -100.00%
BenchmarkScaleCRSrcGray 1 0 -100.00%
BenchmarkScaleCRSrcNRGBA 1 0 -100.00%
BenchmarkScaleCRSrcRGBA 1 0 -100.00%
BenchmarkScaleCRSrcYCbCr 1 0 -100.00%
benchmark old bytes new bytes delta
BenchmarkScaleBLLargeDown 14745600 2949200 -80.00%
BenchmarkScaleCRLargeDown 14745600 4915333 -66.67%
BenchmarkScaleBLDown 1523712 5079 -99.67%
BenchmarkScaleCRDown 1523712 7619 -99.50%
BenchmarkScaleBLUp 10117120 101175 -99.00%
BenchmarkScaleCRUp 10117120 202350 -98.00%
BenchmarkScaleCRSrcGray 4915200 49156 -99.00%
BenchmarkScaleCRSrcNRGBA 4915200 163853 -96.67%
BenchmarkScaleCRSrcRGBA 4915200 163853 -96.67%
BenchmarkScaleCRSrcYCbCr 4915200 245780 -95.00%
The increase in BenchmarkScale??LargeDown number of allocs I think is an
accounting error due to the low number of iterations: a low denominator.
I suspect that there are one or two extra allocs up front for using the
sync.Pool, but one fewer alloc per iteration. The number of iterations
is only 5 for BL and 3 for CR, for the default timeout. If I increase
the -test.benchtime value to 5s, then the reported average (allocs/op)
drop from 2 to 0, so the delta should actually be -100% instead of +0 or
+100%.
Change-Id: I21d9bb0086bdb25517b6a430e8a21bdf3db026f6
Reviewed-on: https://go-review.googlesource.com/8150
Reviewed-by: Rob Pike <r@golang.org>
Also fix the NN and ABL fast paths to only apply if we can access the
Pix elements without src-bounds checking.
Change-Id: Ie9fc96b28e0665df49d00c4c53cb81385faee4db
Reviewed-on: https://go-review.googlesource.com/7675
Reviewed-by: Rob Pike <r@golang.org>
Just stub implementations for now. Actual implementations will be
follow-up changes.
Change-Id: Id21d9042a2073c2dc0f78c9977c4940f000a41df
Reviewed-on: https://go-review.googlesource.com/6805
Reviewed-by: Rob Pike <r@golang.org>
This means that only Kernel values have a NewScaler method, which
re-uses computation when scaling multiple images of the same dst and src
dimensions. The NearestNeighbor and ApproxBiLinear scalers don't get any
pre-computation to re-use, so don't need a NewScaler method just to
satisfy the previous Interpolator interface. As a small bonus, NN.Scale
and ABL.Scale should no longer allocate on the fast paths.
This change is consistent the upcoming Transformer method, so that the
Interpolator interface will be
type Interpolator interface {
Scale(etc)
Transform(etc)
}
instead of
type Interpolator interface {
NewScaler(etc) Scaler
Transform(etc)
}
I don't have a good theory for why the "func (ablInterpolator)
scale_RGBA_RGBA" benchmark is such a dramatic improvement, but at least
it's in the right direction. I'm calling the other benchmark changes as
noise.
benchmark old ns/op new ns/op delta
BenchmarkScaleLargeDownNN 3233406 3169060 -1.99%
BenchmarkScaleLargeDownAB 12018178 12011348 -0.06%
BenchmarkScaleLargeDownBL 1420827834 1409335695 -0.81%
BenchmarkScaleLargeDownCR 2820669690 2795534035 -0.89%
BenchmarkScaleDownNN 866628 869241 +0.30%
BenchmarkScaleDownAB 3175963 3216041 +1.26%
BenchmarkScaleDownBL 26639767 26677003 +0.14%
BenchmarkScaleDownCR 51720996 51621628 -0.19%
BenchmarkScaleUpNN 42758485 43258611 +1.17%
BenchmarkScaleUpAB 156693813 156943367 +0.16%
BenchmarkScaleUpBL 69511444 69621698 +0.16%
BenchmarkScaleUpCR 124530191 124885601 +0.29%
BenchmarkScaleSrcGray 8992205 9129321 +1.52%
BenchmarkScaleSrcNRGBA 9807837 9894466 +0.88%
BenchmarkScaleSrcRGBA 1333188 1104282 -17.17%
BenchmarkScaleSrcUniform 1147788 1162488 +1.28%
BenchmarkScaleSrcYCbCr 12164542 12305373 +1.16%
Change-Id: I2aee6c392eb7437e843260775aed97ce145b4d47
Reviewed-on: https://go-review.googlesource.com/6556
Reviewed-by: Rob Pike <r@golang.org>
Adding fast paths for concrete dst and src image types will be follow-up
changes.
Change-Id: Ib23e3cc46d9c7a52ebd5eddfbad09177b0b421af
Reviewed-on: https://go-review.googlesource.com/5417
Reviewed-by: Rob Pike <r@golang.org>
This is just a copy/paste/rename in anticipation of automatically
generating fast-path code for specific dst-image types and src-image
types, a la the standard library's image/draw package.
Change-Id: If6385b347cb5e1d134b0ce841ef38ed4450a6fef
Reviewed-on: https://go-review.googlesource.com/5252
Reviewed-by: David Symonds <dsymonds@golang.org>
