3on/3off dashing optimization

Without any dashing "optimization"

drawpointsdash_5_5_aa  8888: msecs =  24.43   GPU: msecs =  36.71
drawpointsdash_5_5_bw  8888: msecs =  11.05   GPU: msecs =  14.67
drawpointsdash_3_1_aa  8888: msecs =  15.96   GPU: msecs =  31.00
drawpointsdash_3_1_bw  8888: msecs =  12.85   GPU: msecs =  20.44
drawpointsdash_1_1_aa  8888: msecs =  38.58   GPU: msecs =  61.46
drawpointsdash_1_1_bw  8888: msecs =  34.65   GPU: msecs =  44.79

With 1on/1off "optimization"

drawpointsdash_5_5_aa  8888: msecs =  25.49   GPU: msecs =  37.12
drawpointsdash_5_5_bw  8888: msecs =  11.73   GPU: msecs =  15.68
drawpointsdash_3_1_aa  8888: msecs =  16.36   GPU: msecs =  30.89
drawpointsdash_3_1_bw  8888: msecs =  13.87   GPU: msecs =  21.37
drawpointsdash_1_1_aa  8888: msecs =   8.70   GPU: msecs = 158.68
drawpointsdash_1_1_bw  8888: msecs =   3.56   GPU: msecs =  50.64

With 3on/3off optimization:

drawpointsdash_5_5_aa  8888: msecs =   4.76   GPU: msecs =  32.71
drawpointsdash_5_5_bw  8888: msecs =   2.63   GPU: msecs =  11.21
drawpointsdash_3_1_aa  8888: msecs =  13.28   GPU: msecs =  53.65
drawpointsdash_3_1_bw  8888: msecs =  11.18   GPU: msecs =  17.73
drawpointsdash_1_1_aa  8888: msecs =   8.63   GPU: msecs = 158.20
drawpointsdash_1_1_bw  8888: msecs =   3.43   GPU: msecs =  49.58

So ... the GPU still takes a big hit in the AA cases but is actually okay in the 5x5 case. Raster sees some improvement in the 3x1 case but not as extravagant as in the 5x5 and 1x1 cases. (Note: the addition of the 3x1 logic hasn't impacted the 1x1's performance).

Looking more closely at the 3x1 case, if we draw wrong and call drawPoints instead of expanding the 3x1s into rects (in SkDraw::drawPoints) we get:

drawpointsdash_5_5_aa  8888: msecs =   4.77   GPU: msecs =  33.34
drawpointsdash_5_5_bw  8888: msecs =   2.50   GPU: msecs =  11.21
drawpointsdash_3_1_aa  8888: msecs =   3.59   GPU: msecs =  54.50
drawpointsdash_3_1_bw  8888: msecs =   1.95   GPU: msecs =  17.74
drawpointsdash_1_1_aa  8888: msecs =   8.90   GPU: msecs = 161.27
drawpointsdash_1_1_bw  8888: msecs =   3.43   GPU: msecs =  50.05

So there is something magic about drawing squares.

Top 10 for 1_1_aa:

Running Time	Self		Symbol Name
922.0ms   36.7%	922.0	 	SkARGB32_Blitter::blitV(int, int, int, unsigned char)
481.0ms   19.1%	481.0	 	do_scanline(int, int, int, unsigned int, SkBlitter*)
250.0ms    9.9%	250.0	 	aa_square_proc(PtProcRec const&, SkPoint const*, int, SkBlitter*)
243.0ms    9.6%	243.0	 	SkScan::AntiFillXRect(SkIRect const&, SkRegion const*, SkBlitter*)
217.0ms    8.6%	217.0	 	antifilldot8(int, int, int, int, SkBlitter*, bool)
104.0ms    4.1%	104.0	 	SkScan::AntiFillXRect(SkIRect const&, SkRasterClip const&, SkBlitter*)
56.0ms    2.2%	56.0	 	SkDashPathEffect::asPoints(SkPathEffect::PointData*, SkPath const&, SkStrokeRec const&, SkMatrix const&) const
51.0ms    2.0%	51.0	 	memmove$VARIANT$sse42
17.0ms    0.6%	17.0	 	SkDraw::drawPoints(SkCanvas::PointMode, unsigned long, SkPoint const*, SkPaint const&, bool) const
9.0ms    0.3%	9.0	 	szone_size

Top 10 for 3_1_aa:

Running Time	Self		Symbol Name
319.0ms   14.1%	319.0	 	SkARGB32_Black_Blitter::blitAntiH(int, int, unsigned char const*, short const*)
251.0ms   11.1%	251.0	 	SkScan::AntiFillRect(SkRect const&, SkRegion const*, SkBlitter*)
247.0ms   10.9%	247.0	 	SkDraw::drawRect(SkRect const&, SkPaint const&) const
228.0ms   10.1%	228.0	 	do_scanline(int, int, int, unsigned int, SkBlitter*)
137.0ms    6.0%	137.0	 	SkBlitter::Choose(SkBitmap const&, SkMatrix const&, SkPaint const&, void*, unsigned long)
79.0ms    3.5%	79.0	 	floorf
77.0ms    3.4%	77.0	 	antifilldot8(int, int, int, int, SkBlitter*, bool)
74.0ms    3.2%	74.0	 	ceilf
74.0ms    3.2%	74.0	 	SkARGB32_Blitter::SkARGB32_Blitter(SkBitmap const&, SkPaint const&)
64.0ms    2.8%	64.0	 	SkMatrix::mapPoints(SkPoint*, SkPoint const*, int) const

[bsalomon, 2012-12-06 20:56:10]

On 2012/12/06 19:11:17, robertphillips wrote:

I defer to Mike on this one.

[reed1, 2012-12-06 21:17:30]

Is this CL really a 3on/3off optimization, or is it 

'support partially clipped first and last point' optimization?

Lets talk about this in detail tomorrow. It might be the right impl, but that
first/last size trick seems specific to hori/vert lines only. I wonder if there
is an equivalent hint that would be more general. maybe not.

[robertphillips, 2012-12-07 13:33:54]

Handling the 3on/3off cases seen in the skps required loosening up several of
the restrictions on the 1on/1off case. The observed 3on/3off lines have partial
first and last blocks due to different phases and lengths that weren't multiples
of the interval length. The main change that wasn't required for the 3on/3off
case was support for non-1 widths (for the 3on/3off 3x3 blocks case).

I think the first/last size should also work for non-hori/vert lines but we
would also have to pass back the tangent (and maybe the normal).

Note: this also almost works for circles (w/o partial 1st or last) but they were
being distracting so I left them for later.

[robertphillips, 2012-12-17 17:33:10]

PTAL - I have altered to API to return first & last paths rather than first and
last sizes

[reed1, 2012-12-17 17:59:35]

Do we have a gm or unittest that exercises this? The code "looks" fine, but the
dashing impl seems big/complex, and I don't trust my inspection.

I think the API change is fine.

[robertphillips, 2012-12-17 18:16:24]

We have the dashing3 GM which tests out:
  1on/1off 1x1 squares w/ different phases (i.e. partial 1st & last)
  1on/1off 1x1 squares w/ non-integer length line (partial last)
  1on/1off 3x3 squares w/ different phases (partial 1st & last)
  1on/1off 1x1 & 3x3 circles - not a fast path yet
  1on/1off 1x1 squares w/ a rotation - breaks fast path due to matrix
  3on/3off 3x1 rects w/ different phases (again partial 1st & last)

The dashing GM also tests some of this but not as thoroughly.

The raster tests for these GMs have 3-4 magnitude differences between pre- and
post- this fix. The gpu tests have larger but not un-expected differences.

[reed1, 2012-12-17 18:33:31]

so the existing gms exercise this first/last case? excellent!

lgtm

[robertphillips, 2012-12-17 18:36:52]

Yep - its coverage was expanded way back in
http://code.google.com/p/skia/source/detail?r=6667

[robertphillips, 2012-12-17 18:56:59]

committed as r6851