aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/database/sql/sql.go
diff options
context:
space:
mode:
authorNigel Tao <nigeltao@golang.org>2012-01-20 10:44:22 +1100
committerNigel Tao <nigeltao@golang.org>2012-01-20 10:44:22 +1100
commitab2ea94c609cb2e6b6dd61ceea93a88a7a66b090 (patch)
tree5d0e347fb6dec2b806f0c37dc44cdbe8f580169f /src/pkg/database/sql/sql.go
parent7f4936a1c5d828b39efea48787bb266f4666d95c (diff)
downloadgo-ab2ea94c609cb2e6b6dd61ceea93a88a7a66b090.tar.xz
image: change the YCbCr image's pixel buffers to start at Rect.Min
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
Diffstat (limited to 'src/pkg/database/sql/sql.go')
0 files changed, 0 insertions, 0 deletions