Bug 268744 – [GTK][WPE] Initialize display ID as early as possible

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

In GTK we currently get the display ID when the toplevel window is realized and gets a monitor assigned. This is happening right after the web page is initialized, which means we always create the web page with 0 display ID and right after that a window screen change happens. Because of this we end up creating two display link monitors. We can avoid this by initializing the web view display id as soon as possible using the primary display ID, that in most of the cases will be then one used when the monitor is assigned to the toplevel.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/23856

[EWS]

Committed 274136@main (cad5d7e5ed76): <https://commits.webkit.org/274136@main>

Reviewed commits have been landed. Closing PR #23856 and removing active labels.

[Milan Crha]

This change does not fix the downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=2253099

I mentioned it there, apps like Evolution do not need realtime threads, it's useless there and obviously harmful. I do not know how much possible, but you might better add an option to enable realtime threads per application, off/false by default (to not break all the users and force them to do changes to have it working with newer WebKitGTK, not talking that ancient apps can be running with the latest WebKitGTK, thus you need backwards compatibility), and only those whom really need it can enable it.

[Carlos Garcia Campos]

Ok, let's stop using real time priority for the display link thread and see how it goes.