Looking for bad performance samples on Linux

[wusyong]

We know WebkitGTK isn't that great, and I decide to look into it more recently.
I believe some are because of WebkitGTK, and some could be GTK itself too.
If anyone can show some examples in wry (not tauri examples), I'll see what might be the cause.

[buxx]

Hello, for information, I have terrible performance too. This performance problem is reproducible with epiphany-browser. My system is Ubuntu 20.04, so a little bit dated. I can add more information if needed (ask me command lines to execute).

[MunirG05]

Issue: Native fetch() is extremely slow compared to Firefox and/or Chromium
The issue is reproducible on GNOME Web (epiphany) on Fedora Linux x86_64
Below is a video attached showing the performance of Left: Chromium (Vivaldi) vs Right: WebkitGTK (GNOME Web)
https://cdn.discordapp.com/attachments/1088081730172354600/1088092072281636934/gnome_web.mp4
(Video of Chromium vs WebkitGTK)
Both browsers are running in Incognito mode so there is no caching being done.
Host Machine Specs and Details:
OS: Fedora Linux x86_64
DE: GNOME running with XServer
CPU: Intel i3 2120 @ 3.3GHz (2)
RAM: 8GB @ 1333MHz
I can attach more information if you ask.

[wusyong]

We don't use localhost server to load assets neither wry nor tauri.
For wry, you can use with_custom_protocol, but it requires to load them yourself.
Tauri, on the other hand, will embed assets into binary in release. So it can load pretty fast.

[FabianLars]

@wusyong If i understood this correctly on discord, this also concerns the browser's built-in fetch, they just showed page load speed because it's easier to see visually.

https://discord.com/channels/616186924390023171/1088081730172354600

[FabianLars]

Cross-linking 2 new issues from the tauri repo:
tauri-apps/tauri#7021
tauri-apps/tauri#7183

[StandingPadAnimations]

For the Phanpy Tauri wrapper, it was found that accelerated compositing actually slowed down UI loading when expanding images on posts with multiple images (cheeaun/phanpy#181). Setting WEBKIT_DISABLE_COMPOSITING_MODE to 1 actually solved the issue (at the cost of making everything else slower), likely due to resizing. To quote from the GitHub issue:

Video of me clicking an image in a post with a single image vs an image in a post with multiple images. In the latter, no matter how much I click or press ESC, the image won't exit

2023-07-04.23-02-02.mp4

[imgurbot12]

Hello, I'm having issues with initial rendering times and have setup a small repo (https://github.com/imgurbot12/wry-test) that can hopefully demonstrate the issues I'm having. I was notified about the source of this issue after my conversations with the dioxus team in DioxusLabs/dioxus#1636 which make use of wry for desktop implementations.

The time to initial render even on my super speedy computer is longer than one second to even see the window which is a long time for my application launcher. I've had difficulties reproducing the problems I've had in the past reliably, but on my slow laptop sometimes it can take over 5 seconds. I even had it take over 10 seconds a while back.

Are there any options to help available within webkit or gtk to help improve on the startup performance?

[imgurbot12]

I have zero expertise on this subject whatsoever, but I've been experimenting with alternative solutions and this project with bindings to webview is about 3-5 times faster on initial rendering than wry despite also using gtkwebkit2.

Perhaps someone from the wry team can take inspiration from their work. the webview project seems to be relatively small for what it does.