3

I have some weird performance issues with a custom view. Here is a simplified example :

protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);

    canvas.drawBitmap(bitmap, 0, 0, null);
    canvas.drawText("test", 0, 30, textPaint);
}

bitmap is a small background image. A string is drawn on top with a large text size so the top 10 (or so) pixels are cropped, which is what I want.

I have around 100 views like this in a ListView (10 per row). Scrolling through the list is incredibly slow, but for some strange reason, it suddenly becomes smooth if I change the drawText() coordinates so that the text fits within the bounds of the view.

What is going on? Why is it so slow to draw the text slightly outside of the bounds?

I'm running Android 4.2.2 (can't try on other versions, the emulator isn't great to test layout performance).

Dalmas
  • 26,409
  • 9
  • 67
  • 80
  • Just for experimenting, can you add `android:clipChildren=true` and `android:clipToPadding=true` to the parent of this view. – Sherif elKhatib Oct 24 '13 at 15:09
  • @SherifelKhatib It didn't change anything. – Dalmas Oct 24 '13 at 20:54
  • oh am sorry. I meant `=false` – Sherif elKhatib Oct 24 '13 at 21:30
  • It is very possible that code takes a different path. May be (I couldn't find pointers for this, that's why it is a may) in case of different bounds (drawing outside) Skia first creates a buffer, draw on that, blit that buffer on top of target. Or again it is a different code path but with more calculation. If I would try to improve this, I would pre-render texts into buffers and render them instead of drawing text everytime. – auselen Oct 25 '13 at 12:20
  • I think Skia applies clipping per glyph (letter) when you draw over bounds, which would make things slow. See SkBounder::doIRectGlyph in SkDraw.cpp. So you would need to do your own caching. I hope you're also playing nice with custom view / list work and don't necessarily make extra work. – auselen Oct 25 '13 at 12:55
  • 1
    @auselen It seems that you're right. After further testing, and tracking native memory heap, when the text is drawn outside of the bounds there's almost twice as much memory used than if drawn inside. By the way `android:clipChildren=false` does speeds up things a bit, but it's still much slower than with caching. You can put your comment as an answer and I will accept it. – Dalmas Oct 28 '13 at 07:39

1 Answers1

1

It is possible that Skia needs to do extra calculation and allocation per glyph (letter) which is out of bound.

If this situation was just about text being out of screen on the left or right, or like when you have full screen text and only top and/or bottom line is half visible then such performance problem would be ignorable. However in your case you do this more than what Skia developers assumed. This might get better with later Android releases, but it looks like at the moment it is an unoptimized case.

For the wondering, I believe related code is in SkDraw.cpp around SkBounder::doIRectGlyph.

Proper way to find this bottle neck would be to use a native execution tracer like perf, oprofile or ARM DS-5 Streamline.

auselen
  • 27,577
  • 7
  • 73
  • 114