RESOLVED FIXED268744
[GTK][WPE] Initialize display ID as early as possible 
https://bugs.webkit.org/show_bug.cgi?id=268744
Summary [GTK][WPE] Initialize display ID as early as possible
Carlos Garcia Campos
Reported 2024-02-05 06:50:29 PST
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.
Attachments
Add attachment proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1 2024-02-05 06:53:43 PST
Pull request: https://github.com/WebKit/WebKit/pull/23856
EWS
Comment 2 2024-02-06 01:30:18 PST
Committed 274136@main (cad5d7e5ed76): <https://commits.webkit.org/274136@main> Reviewed commits have been landed. Closing PR #23856 and removing active labels.
Milan Crha
Comment 3 2024-02-06 23:21:52 PST
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
Comment 4 2024-02-07 00:36:09 PST
Ok, let's stop using real time priority for the display link thread and see how it goes.
Note You need to log in before you can comment on or make changes to this bug.