IssueTracker

sgtm, we can add the same API for FileSpec:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/compiler-processing/src/main/java/androidx/room/compiler/processing/XFiler.kt;l=28?q=XFiler.kt&ss=androidx%2Fplatform%2Fframeworks%2Fsupport

I recommend using github for a small checkout size: https://github.com/androidX/androidx

Looks like we do have kotlin poet in the repo: https://github.com/androidx/androidx/blob/androidx-main/buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt#L75

So just need to add it as an API dependency to the room-compiler-processing's build file.

If you can add a test to the generated code match test, that would be great: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/compiler-processing-testing/src/test/java/androidx/room/compiler/processing/util/GeneratedCodeMatchTest.kt

lmk if you hit any blocker in getting started, thanks!

All

Seems to only happen with Graphite enabled.

Looking at the fix in https://g-issues.chromium.org/issues/40217853, my guess is that this web page has a lot of text with box-shadow CSS, and the text is large enough to trigger path-based rendering. In Graphite right now, these mask filters are converted to image filters to compute the blur, but without texture reuse and atlasing, we are probably getting into a pathological state.

Graphite is only enabled on canary for now, and I will check performance as the texture and renderpass work progresses to see if that alleviates the issue. Ganesh got around this by caching the blurred path masks across frames at the expense of increased memory usage. Image filters are never cached in skia, so the current mask filter -> image filter pipeline that I'm moving skia and graphite to would not support the previous fix. This may mean that global filter caching will have to be handled somehow.

CC'ing Quyen as these are good real-world sites to look into as we burn down performance issues. At face value I didn't a lot of box shadow use in theverge.com or macrumors.com, but it's perhaps subtle. Alternatively, these were very long pages with lots of images and (possibly?) embedded content. Perhaps this is exacerbating tile submission or access issues?

Mehmet, is this still happening for you on the latest Canary on Mac ARM? We've made a ton of performance improvements since the original bug was filed and hopefully this issue is fixed now.

Thank you for providing more feedback. Adding the requester to the CC list.

Thank you for the additional report. The original bug seemed to be related to missed caching of box-shadow masks. In the videos on comment #14, it appears more like tearing or missed tiles that weren't ready by compositing. This could still be caused by box-shadows taking too long to render with graphite so the tile raster times are higher. That said, the issue shown in comment #16 shows significant missed tiles for something that is very simple, just text. That might indicate some more fundamental issue with pre-rendering or timing of frames and tiles in graphite that could contribute to both of these cases. I will bump up the priority and try and dig into it more.

I see occasional hangs of 100-200ms in the GPU process in IOSurfaceImageBacking::WaitForDawnCommandsToBeScheduled. These are preceded by large bursts of raster commands - just decoding the commands takes something like 10-20ms so that's just a lot of work being submitted. It's unclear if this is a bug in the page e.g. extending the 2d canvas path indefinitely or just a pathological case.

Just to confirm, this trace was captured for https://stadt-bremerhaven.de/ right? Can you please also collect a trace with chrome://flags#skia-graphite disabled just to compare. I'll try reproducing this locally too.