haze icon indicating copy to clipboard operation
haze copied to clipboard

[0.4.5] Webview flashing when using with haze

Open wezley98 opened this issue 1 year ago • 4 comments

Looks like haze is having issues with Webviews, Our QA's found this in our real app code we we had to revert for now, but I've created a simple example to reproduce here: Just a fork with a webview sample added. Had to drop toolchain to 17 but that's nothing to do with the issue just my current setup.

https://github.com/wezley98/haze_webview_test/commit/82427efbe9c2371c8406129b0368ed8e0c557d78

API 34 emulator

Screen_recording_20240115_105304.webm

For our usecase: most of the app is native which works fine with the bottombar and haze. But some screens are still been migrated away from webviews, when using haze with webviews we see this repeated flashing issue.

wezley98 avatar Jan 15 '24 10:01 wezley98

Hmmm. Looks like an invalidation issue when using AndroidViews underneath, where we need to invalidate a lot. We can look at potential issues with invalidating too much, but that's about it.

chrisbanes avatar Jan 15 '24 11:01 chrisbanes

Yes, jetpack-compose

wezley98 avatar Jan 15 '24 11:01 wezley98

FYI: one of the issues in your sample is that you are calling loadUrl in the update block, which means that you'll be calling loadUrl on every composition. This is why the video above is so bad (as it's constantly reloading the URL).

Even fixing that, there is an issue here for when the web content changes. The problem seems to be something around drawing WebViews in a RenderNode with a RenderEffect. Drawing it once works fine but drawing it multiple times (for the blurred areas) leads to the flashing. If I remove the RenderEffect, but still draw the RenderNode again for the blurred areas, it works fine too.

I initially thought it might be caused by skipping loads of frames, but I don't think that is the case. See the screenshot below. We're in and around the yellow line, which is good (enough here anyway). If we were skipping enough frames to lead to the flashing above, you'd expect lots of spikes past the red line.

Screenshot_1705320269

I'll leave this open, but I'm not sure there's much we can do here. I do want to spend some time optimizing the draw paths which might help this issue.

chrisbanes avatar Jan 15 '24 12:01 chrisbanes

Thanks for looking into this, I'll look at a way for us conditionally turn off haze when we are using webviews for now.

wezley98 avatar Jan 15 '24 12:01 wezley98

I'm pretty sure that this is actually fixed in Haze 0.9, so going to close this. The new drawing pipeline means that everything is drawn in the child, not the parent.

chrisbanes avatar Oct 26 '24 12:10 chrisbanes

Would be interesting to know if this actually fixed the issue. As an aside, we discovered that calling setLayerType(HARDWARE,null) on our WebView resolved flickering while doing a similar technique as older haze.

pfn avatar Oct 27 '24 04:10 pfn

Very quick demo:

https://github.com/user-attachments/assets/4df49b80-1b64-497b-b1b7-f33cf5c23d56

There's still some flickering, but nowhere near as much as previously.

chrisbanes avatar Oct 27 '24 09:10 chrisbanes