It's amazing bugs like this persist, even with the significant resources of several megacorps allocating legions of full-time developers to the codebase.
Summary: In certain circumstances webview rendering is slow because it has to integrate with the android rendering API incase an app wishes to synchronize some App UI with web UI.
This isn't a limitation in chrome itself, which means chrome rendering has better performance for these specific operations (animations mostly).
Personally I think the chrome rendering path should always be used, and apps which want to draw under/over web content will have to deal with a frame or two of delay.
About a decade ago iOS only had UIWebView which was significantly worse than Safari. This affected all apps using a webview including competing browsers.
7 comments
[ 2.8 ms ] story [ 22.3 ms ] threadBasically, FB's engineering replaced it with a full chromium based webview and explained the reasons android webview sucks ass.
This isn't a limitation in chrome itself, which means chrome rendering has better performance for these specific operations (animations mostly).
Personally I think the chrome rendering path should always be used, and apps which want to draw under/over web content will have to deal with a frame or two of delay.
About a decade ago iOS only had UIWebView which was significantly worse than Safari. This affected all apps using a webview including competing browsers.