SkBitmapDevice::drawImageRect is slow on Android device

32 views
Skip to first unread message

程洋

unread,
Jul 31, 2024, 10:38:07 AMJul 31
to skia-discuss

When debugging our phone, we found that the first frame when opening a desktop folder is very slow. After investigation, we discovered that the slowness occurs during the icon drawing process. In the call stack, it eventually calls our program's com.miui.home.launcher.graphics.drawable.LayerAdaptiveIconDrawable.draw. Delving deeper, we found that a single call to SkBitmapDevice::drawImageRect takes 6ms. If there are 8 icons in a folder, it takes 48ms. However, the size of a single icon is only 200*200.

But once the first frame has passed, subsequent calls to LayerAdaptiveIconDrawable.draw become much faster, around 100us.

Since the slowdown occurs within a Skia function and eventually seems to be an anonymous function after compilation, we do not understand why it is slow at this point.

Can anyone provide some insights?

1.jpeg

John Stiles

unread,
Jul 31, 2024, 12:46:27 PMJul 31
to skia-d...@googlegroups.com
Is it intentional that you are using a CPU-backed surface and not GPU-backed? If you are concerned about performance, using a GPU surface will be faster. I can't tell if this is the reason for the performance hiccup on the first draw, but it is certainly the first thing I'd address if speed is an issue.

Also—is the slowdown still present if you close and reopen the same window? If it's fast a second time, it might just be that the icon data was not resident in memory at all and needed to be paged in. But that's just a guess. From Skia's perspective, there isn't any reason why a second CPU draw would be much faster than the first.


--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/5b54f9be-9e7f-4ce8-bfe0-d738829cb011n%40googlegroups.com.

程洋

unread,
Jul 31, 2024, 10:30:49 PMJul 31
to skia-discuss
I'm not sure if it's CPU or GPU calculation because we just call the Android frameworks draw API. seems there is nothing for us to control if it's CPU or GPU.
And yes. it's still slow when we open it again. We already checked the high level object, it's the same hash code.

We still have no clue

John Stiles

unread,
Jul 31, 2024, 10:39:34 PMJul 31
to skia-d...@googlegroups.com
I am not an Android canvas expert, but it looks like this is how you would control GPU acceleration on Android. https://developer.android.com/develop/ui/views/graphics/hardware-accel#controlling

Based on that stack, I am sure that you are currently using the CPU.


程洋

unread,
Aug 12, 2024, 8:44:02 AMAug 12
to skia-discuss
The following code in the Android frameworks is responsible for drawing adaptive icons, and it indeed involves off-screen rendering, where two icons are first composited into one. However, we are puzzled by the fact that rendering a 234x234 image should not take 4ms, even when using the CPU. We don't quite understand what Skia is doing in this process, especially since the final function called has been compiled via p.compile.
Reply all
Reply to author
Forward
0 new messages