Open p2004a opened 2 years ago
This is somewhat of a known issue, even windows marks spring as not responding during load... Maybe we should pump events more?
Does it produce any stacktrace?
Nope, there isn't any stacktrace, here is the relevant end of the log:
[t=00:00:33.770869][f=-000001] [~ScopedOnceTimer][CArchiveScanner::ScanAllDirs] 4ms
{"name":"Download","command":{"name":"Kolmogorov Remake 3.0","type":"map"}}
spring->launcher Download { name: 'Kolmogorov Remake 3.0', type: 'map' }
Download started: Kolmogorov Remake 3.0
pr-downloader 0.7-621-g34cf14a (linux64)
[Info] /spring/tools/pr-downloader/src/FileSystem/FileSystem.cpp:188:setWritePath():Using filesystem-writepath: /home/p2004a/Documents/Beyond All Reason
[Info] /spring/tools/pr-downloader/src/pr-downloader.cpp:178:DownloadSetConfig():Free disk space: 305625 MB
[Info] /spring/tools/pr-downloader/src/Downloader/CurlWrapper.cpp:66:DumpVersion():libcurl 7.73.0 OpenSSL/1.1.1i
[Warn] /spring/tools/pr-downloader/src/Downloader/CurlWrapper.cpp:42:GetTLSBackend():SSL backend warning/error (1)
[Info] /spring/tools/pr-downloader/src/Downloader/CurlWrapper.cpp:46:GetTLSBackend():SSL backend #0: 'openssl' (ID: 1)
[Info] /spring/tools/pr-downloader/src/Downloader/Http/HttpDownloader.cpp:292:verifyAndGetNextPieces():md5 sum missmatch e0b2b0665127e10eab85f121b2fe5967 00000000000000000000000000000000
[Progress] 0% [ ] 295978/121964431
[Progress] 29% [======== ] 35103978/121964431
Download progress: Kolmogorov Remake 3.0, 35103978, 121964431
launcher->spring {"name":"DownloadProgress","command":{"name":"Kolmogorov Remake 3.0","progress":0.2878214386946962,"total":121964431}}
[Progress] 67% [==================== ] 82127978/121964431
Download progress: Kolmogorov Remake 3.0, 82127978, 121964431
launcher->spring {"name":"DownloadProgress","command":{"name":"Kolmogorov Remake 3.0","progress":0.6733764698988347,"total":121964431}}
[Progress] 100% [==============================] 121964431/121964431
launcher->spring {"name":"DownloadProgress","command":{"name":"Kolmogorov Remake 3.0","progress":1,"total":121964431}}
[Info] /spring/tools/pr-downloader/src/main.cpp:239:main():Download complete!
Download finished: Kolmogorov Remake 3.0
launcher->spring {"name":"DownloadFinished","command":{"name":"Kolmogorov Remake 3.0","isSuccess":true,"isAborted":false}}
[t=00:00:43.022660][f=-000001] Scanning: /home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/base
[t=00:00:43.024735][f=-000001] Scanning: /home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/maps
[t=00:00:43.024787][f=-000001] Scanning: /home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/games
[t=00:00:43.024822][f=-000001] Scanning: /home/p2004a/Documents/Beyond All Reason/maps
[t=00:00:43.025225][f=-000001] Scanning: /home/p2004a/Documents/Beyond All Reason/packages
[t=00:00:48.663587][f=-000001] Warning: [AS::ScanArchive] set the 'mapfile' key in mapinfo.lua of archive "/home/p2004a/Documents/Beyond All Reason/maps/kolmogorov_remake_3.0.sd7" for faster loading!
[t=00:00:48.684451][f=-000001] [~ScopedOnceTimer][CArchiveScanner::ScanAllDirs] 5661ms
[t=00:00:48.923661][f=-000001] [SpringApp::Kill][1] fromRun=1
[t=00:00:48.923726][f=-000001] [ThreadPool::SetThreadCount][1] wanted=0 current=8 maximum=16 (init=0)
[t=00:00:48.953993][f=-000001] [async=0] threads=8 tasks=301 {sum,avg}{exec,wait}time={{114.294, 0.380}, {115.466, 0.384}}ms
[t=00:00:48.954058][f=-000001] thread=1 tasks=43 {sum,min,max,avg}{exec,wait}time={{19.597, 0.000, 1.670, 0.456}, {0.074, 0.000, 0.019, 0.002}}ms
[t=00:00:48.954078][f=-000001] thread=2 tasks=43 {sum,min,max,avg}{exec,wait}time={{17.483, 0.001, 1.662, 0.407}, {1.627, 0.000, 0.188, 0.038}}ms
[t=00:00:48.954271][f=-000001] thread=3 tasks=43 {sum,min,max,avg}{exec,wait}time={{16.892, 0.000, 1.673, 0.393}, {2.624, 0.000, 0.382, 0.061}}ms
[t=00:00:48.954309][f=-000001] thread=4 tasks=43 {sum,min,max,avg}{exec,wait}time={{14.479, 0.000, 1.648, 0.337}, {6.006, 0.002, 1.285, 0.140}}ms
[t=00:00:48.954325][f=-000001] thread=5 tasks=43 {sum,min,max,avg}{exec,wait}time={{12.320, 0.000, 1.553, 0.287}, {39.971, 0.000, 30.059, 0.930}}ms
[t=00:00:48.954369][f=-000001] thread=6 tasks=43 {sum,min,max,avg}{exec,wait}time={{17.054, 0.001, 1.651, 0.397}, {32.175, 0.000, 30.061, 0.748}}ms
[t=00:00:48.954387][f=-000001] thread=7 tasks=43 {sum,min,max,avg}{exec,wait}time={{16.469, 0.000, 1.649, 0.383}, {32.989, 0.002, 30.065, 0.767}}ms
[t=00:00:48.954400][f=-000001] [async=1] threads=8 tasks=7 {sum,avg}{exec,wait}time={{2.798, 0.400}, {1.121, 0.160}}ms
[t=00:00:48.954411][f=-000001] thread=1 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.110, 0.110, 0.110, 0.110}, {0.324, 0.324, 0.324, 0.324}}ms
[t=00:00:48.954423][f=-000001] thread=2 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.115, 0.115, 0.115, 0.115}, {0.346, 0.346, 0.346, 0.346}}ms
[t=00:00:48.954434][f=-000001] thread=3 tasks=1 {sum,min,max,avg}{exec,wait}time={{1.026, 1.026, 1.026, 1.026}, {0.256, 0.256, 0.256, 0.256}}ms
[t=00:00:48.954445][f=-000001] thread=4 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.253, 0.253, 0.253, 0.253}, {0.041, 0.041, 0.041, 0.041}}ms
[t=00:00:48.954456][f=-000001] thread=5 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.093, 0.093, 0.093, 0.093}, {0.056, 0.056, 0.056, 0.056}}ms
[t=00:00:48.954467][f=-000001] thread=6 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.232, 0.232, 0.232, 0.232}, {0.018, 0.018, 0.018, 0.018}}ms
[t=00:00:48.954478][f=-000001] thread=7 tasks=1 {sum,min,max,avg}{exec,wait}time={{0.970, 0.970, 0.970, 0.970}, {0.080, 0.080, 0.080, 0.080}}ms
[t=00:00:48.954489][f=-000001] [ThreadPool::SetThreadCount][2] workers=0
[t=00:00:48.954498][f=-000001] [SpringApp::Kill][2]
[t=00:00:48.954538][f=-000001] [Sound] [Sound::Kill] soundThread.joinable()=1
[t=00:00:48.976189][f=-000001] [WatchDog::DeregisterThread] deregistering controls for thread [audio]
[t=00:00:48.976223][f=-000001] [Sound] [Sound::UpdateThread][3] #sources=255 #items=1
[t=00:00:48.976443][f=-000001] [Sound] [Sound::UpdateThread][4] ctx=0x7f333001b970 dev=0x7f3330009540
[t=00:00:48.976537][f=-000001] [Sound] [Sound::UpdateThread][5] ctx=0x7f333001b970 dev=0x7f3330009540
[t=00:00:48.976547][f=-000001] [Sound] [Sound::Cleanup][alcDestroyContext(0x7f333001b970)]
[t=00:00:48.977921][f=-000001] [Sound] [Sound::Cleanup][alcCloseDevice(0x7f3330009540)]
[t=00:00:48.978735][f=-000001] [Sound] [Sound::UpdateThread][6]
[t=00:00:48.989962][f=-000001] Remember to update handler.lua once the following is in basecontent: https://github.com/spring/spring/commit/ef6df34ae5dd4eba9b192f695f9b2724da0f83c2
[t=00:00:48.990045][f=-000001] Scenario Window GetConfigData
[t=00:00:48.991765][f=-000001] [Chobby] Chobby Shutdown
bridge: connection to Spring lost.
[t=00:00:49.059225][f=-000001] [LuaMemPool::LogStats][handle=LuaMenu (unsynced)] index=0 {numAllocs[*],allocSums[*]}={0,0} {int,ext,rec}Allocs={0,3908409,0} {chunk,block}Bytes={0,0}
[t=00:00:49.059389][f=-000001] [SpringApp::Kill][3]
[t=00:00:49.059398][f=-000001] [SpringApp::Kill][4] font=0x563679e89f00
[t=00:00:49.059466][f=-000001] [SpringApp::Kill][5]
[t=00:00:49.075440][f=-000001] [SpringApp::Kill][6]
[t=00:00:49.075459] [SpringApp::Kill][7]
[t=00:00:49.086905] [LuaSocket] [~CLuaSocketRestrictions] dumping luasocket rules:
[t=00:00:49.086927] [LuaSocket] TCP_CONNECT ALLOW * -1
[t=00:00:49.086940] [LuaSocket] TCP_LISTEN ALLOW * -1
[t=00:00:49.086945] [LuaSocket] UDP_LISTEN ALLOW * -1
[t=00:00:49.087084] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>]
[t=00:00:49.087093] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=0)] #archives[section]=0 #files[section]=0
[t=00:00:49.087101] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=1)] #archives[section]=0 #files[section]=0
[t=00:00:49.087108] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=2)] #archives[section]=3 #files[section]=439
[t=00:00:49.087114] [VFS] archive=/home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/base/springcontent.sdz (0x7f3370065750)
[t=00:00:49.087158] [VFS] archive=/home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/base/spring/bitmaps.sdz (0x563679c03100)
[t=00:00:49.087180] [VFS] archive=/home/p2004a/.var/app/info.beyondallreason.bar/data/engine/105.1.1-898-g7b6a594 bar/base/cursors.sdz (0x563679e5ed20)
[t=00:00:49.087228] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=3)] #archives[section]=2 #files[section]=3449
[t=00:00:49.087235] [VFS] archive=/home/p2004a/Documents/Beyond All Reason/packages/8f292366bbeb6a0780811f6ad2f0d301.sdp (0x563679fe8990)
[t=00:00:49.087252] [~CPoolArchive] archiveFile="/home/p2004a/Documents/Beyond All Reason/packages/8f292366bbeb6a0780811f6ad2f0d301.sdp" numZipFiles=1035 sumInflSize=104263kb sumReadTime=95ms
[t=00:00:49.087260] file="luamenu/configs/gameconfig/byar/lobbymusic/original/ryan krause - friend or foe (intro).ogg" indx=308 inflSize=4134kb readTime=11ms
[t=00:00:49.087265] file="luamenu/configs/gameconfig/byar/skinning/loadpictures/bar4k_loadingscreen_1.jpg" indx=872 inflSize=1010kb readTime=3ms
[t=00:00:49.087270] file="luamenu/configs/gameconfig/byar/minimapoverride/aberdeen3v3v3.jpg" indx=315 inflSize=348kb readTime=2ms
[t=00:00:49.087275] file="luamenu/configs/gameconfig/byar/minimapoverride/kolmogorov_remake_3.0.jpg" indx=379 inflSize=272kb readTime=1ms
[t=00:00:49.087280] file="luamenu/configs/gameconfig/byar/skinning/headinglarge.png" indx=868 inflSize=1057kb readTime=1ms
[t=00:00:49.087285] file="luamenu/configs/gameconfig/byar/minimapoverride/comet_catcher_remake_1.8.jpg" indx=338 inflSize=275kb readTime=1ms
[t=00:00:49.087290] file="luamenu/configs/gameconfig/byar/minimapoverride/altair_crossing_v4.jpg" indx=319 inflSize=348kb readTime=1ms
[t=00:00:49.087295] file="luamenu/configs/gameconfig/byar/minimapoverride/deserttriad.jpg" indx=342 inflSize=401kb readTime=1ms
[t=00:00:49.087301] file="luamenu/configs/gameconfig/byar/minimapoverride/dworld_v3.jpg" indx=348 inflSize=319kb readTime=1ms
[t=00:00:49.087306] file="luamenu/configs/gameconfig/byar/minimapoverride/knockoutr_1.5.jpg" indx=377 inflSize=315kb readTime=1ms
[t=00:00:49.087462] [VFS] archive=/home/p2004a/Documents/Beyond All Reason/packages/3a62f6a588a2035017c5e46f98d1a075.sdp (0x563679fcb170)
[t=00:00:49.087501] [~CPoolArchive] archiveFile="/home/p2004a/Documents/Beyond All Reason/packages/3a62f6a588a2035017c5e46f98d1a075.sdp" numZipFiles=2654 sumInflSize=177316kb sumReadTime=42ms
[t=00:00:49.087512] file="luamenu/images/heic1403adowngrade.jpg" indx=1916 inflSize=6329kb readTime=7ms
[t=00:00:49.087517] file="luamenu/images/starbackgrounds/2.jpg" indx=2106 inflSize=258kb readTime=1ms
[t=00:00:49.087523] file="luamenu/images/starbackgrounds/1.jpg" indx=2105 inflSize=242kb readTime=1ms
[t=00:00:49.087529] file="luamenu/images/starbackgrounds/4.jpg" indx=2108 inflSize=252kb readTime=1ms
[t=00:00:49.087534] file="luamenu/images/starbackgrounds/3.jpg" indx=2107 inflSize=178kb readTime=0ms
[t=00:00:49.087540] file="luamenu/images/chobbyinabox.png" indx=1621 inflSize=195kb readTime=0ms
[t=00:00:49.087546] file="luamenu/images/planets/arid01.png" indx=2022 inflSize=131kb readTime=0ms
[t=00:00:49.087551] file="luamenu/images/planets/barren01.png" indx=2023 inflSize=127kb readTime=0ms
[t=00:00:49.087556] file="luamenu/images/planets/terran03_damaged.png" indx=2060 inflSize=122kb readTime=0ms
[t=00:00:49.087562] file="luamenu/images/planets/tundra01.png" indx=2062 inflSize=92kb readTime=0ms
[t=00:00:49.087816] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=4)] #archives[section]=0 #files[section]=111
[t=00:00:49.087826] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=5)] #archives[section]=0 #files[section]=0
[t=00:00:49.087832] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=6)] #archives[section]=0 #files[section]=0
[t=00:00:49.087838] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=7)] #archives[section]=0 #files[section]=0
[t=00:00:49.087844] [VFS] [SpringVFS::DeleteArchives<this=0x7f3370071180>(section=8)] #archives[section]=0 #files[section]=0
[t=00:00:49.087947] [SpringApp::Kill][8]
[t=00:00:49.087955] [WatchDog::DeregisterThread] deregistering controls for thread [main]
[t=00:00:49.087961] [WatchDog::Uninstall][1] hangDetectorThread=0x5636368fc9d0 (joinable=1)
[t=00:00:49.087987] [WatchDog::Uninstall][2]
[t=00:00:50.027047] [WatchDog::Uninstall][3]
[t=00:00:50.027074] [SpringApp::Kill][9]
spring: fccache.c:548: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
Spring failed with code: null
[1877474:0413/215217.253514:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[1877474:0413/215217.256882:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
Update: I did a bit more debugging and I'm not sure if this is purely bug in spring anymore, but maybe also in SDL2.
Running the game with WAYLAND_DEBUG=1
and patched local build of spring that includes:
bool SpringApp::MainEventHandler(const SDL_Event& event)
{
LOG("event: %s", sdlEventToString(event).c_str());
(...)
(using https://github.com/jwurzer/sdl-event-to-string)
Here is the interesting portion of log: https://gist.github.com/p2004a/4ad811af9928e5846bb5cb17ef7dd156. Note the last coordinates in line 12 and 143 match.
What happens it that window suddenly disappears, but spring continues running without display, executed some things and then get the stream of events with SDL_QUIT
at the end, after some time closing down the whole process. In syslog I see following logline at the same time when crash happens:
gnome-shell[3996]: WL: error in client communication (pid 80718)
We have now 3 different pieces interacting: compositor, SDL2, spring. Spring not processing events causes the crash, but it's not clear to me that that should be actual behavior and whatever there is bug in SDL2 or compositor.
Update: I've done a bunch more testing and I'm pretty sure it's a bug in SDL2: https://github.com/libsdl-org/SDL/issues/5536
It would be cool if the spring didn't become unresponsive, but I expect that would be quite a lot of work?
Yep, looks so. WL support in BAR/spring is currently experimental and lacks some features, for example the support for hardware cursor. This one hints WL is less usable than initially imagined. IDK if it will be solved upstream or not, but even if it does, it will take a few years for distros to update SDL2. Previous attempts to link SDL2 statically failed. So, I'm afraid I don't have too many good news here.
As far as loading and unresponsiveness... this is rather complicated. Some loading operations are expected to run on the main thread on most of the drivers and will crash otherwise. So probably the best we can do is to place event pump calls in between the heavy calls, which I thought we did in most of the cases. Can you see what stage of loading you're crashing at, so I can double check the code?
Perhaps we're not a doing WL a favor when we call:
spring::UnfreezeSpring(WDT_LOAD, 10);
I don't have PC at the moment, but since you're on it, can you comment out the call above
in void ModelPreloader::Load{Unit,Feature,Weapon}Defs()
?
I think the opposite direction, changing to spring::UnfreezeSpring(WDT_LOAD, 1)
has some potential but, now, with more tests (see the linked SDL bug, I was mostly root causing there, fix probably isn't possible at SDL level) I don't believe this is feasible to resolve at spring side. TLDR: with current state in multiple different upstream projects, even a break like ~200ms in processing events can be enough for things to fall over. 200ms is very little, some lua code in Chobby takes more (e.g. opening "Change Map" dialog"). Plenty of games will have issue with this.
IDK if it will be solved upstream or not, but even if it does, it will take a few years for distros to update SDL2. Previous attempts to link SDL2 statically failed. So, I'm afraid I don't have too many good news here.
And IMHO that's fine. Sadly still trying to use wayland with anything on distros released years ago is just not realistic and asking for issues. I'm trying to investigate/fix/report things not working on wayland, but I have a very clear expectation that I can't just sit on Ubuntu LTS and expect that things will be backported.
I think this bug could be closed, I don't expect any action on spring side for this. (but maybe you want to keep it open in case other people run into it when testing wayland?)
FYI: there is workaround until this gets 100% properly fixed in one of the upstream projects. Run spring with environment variable LIBDECOR_PLUGIN_DIR=null
set, this will not show window decorations (I expect people run spring mostly in fullscreen anyway), but it will prevent crashing (At least under Gnome 42).
Ah, so that's why I was not able to reproduce in Sway
FYI: there is workaround until this gets 100% properly fixed in one of the upstream projects.
should we add it to flatpak?
I tested weston and mutter on gnome and they're both affected. LIBDECOR_PLUGIN_DIR=null
helps a lot, but it is still possible to crash the window by moving the mouse erratically.
Maybe there's a way to workaround the issue by dropping the mouse events somehow for the duration of the loading?
Crashes on wayland are even more frequent on full screen (when SDL driver runs as x11 and receives window events). One of the reasons for that might be that SDL is causing spurious window resize events that take very long time to process (1500 ms in my example below). Some SDL versions are triggering additional SDL_WINDOWEVENT_SIZE_CHANGED and/or SDL_WINDOWEVENT_MOVED (Fedora 37). Pure wayland is not receiving these events so we might consider starting app with SDL_VIDEODRIVER=wayland instead of x11 (when desktop is on wayland).
https://github.com/libsdl-org/SDL/issues/5710 window move bug https://github.com/libsdl-org/SDL/pull/5232 spurious resize
[t=00:00:08.505479][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_SHOWN][1] fullScreen=1
[t=00:00:08.505490][f=-000001] [~ScopedOnceTimer][Sound::Iconified] 0ms
[t=00:00:08.505497][f=-000001] [~ScopedOnceTimer][FBO::GLContextReinit] 0ms
[t=00:00:08.505504][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_SHOWN][2]
[t=00:06:05.402746][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_MOVED][1] di=0, ssx=2560, ssy=1440, wsx=2560, wsy=1440, wpx=0, wpy=0
[t=00:06:05.402769][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_MOVED][2] di=0, ssx=2560, ssy=1440, wsx=1920, wsy=1200, wpx=0, wpy=0
[t=00:06:05.402782][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_SIZE_CHANGED][1] fullScreen=1
[t=00:06:05.402791][f=-000001] [GR::UpdateGLConfigs]
[t=00:06:05.402853][f=-000001] [GR::UpdateGLGeometry][1] winSize=<1920,1200>
[t=00:06:05.402876][f=-000001] [GR::UpdateScreenMatrices] vpx=0.000000, vpy=240.000000, vsx=1920.000000, vsy=1200.000000, ssx=2560.000000, ssy=1440.000000, screenPosX=0, screenPosY=0
[t=00:06:05.402886][f=-000001] [GR::UpdateGLGeometry][2] winSize=<1920,1200>
[t=00:06:05.402892][f=-000001] [GR::InitGLState]
[t=00:06:05.402964][f=-000001] [GR::LogDisplayMode] display-mode set to 1920x1200x24bpp@75Hz (fullscreen::non-exclusive)
[t=00:06:05.402975][f=-000001] [~ScopedOnceTimer][GlobalRendering::UpdateGL] 0ms
[t=00:06:05.402982][f=-000001] [~ScopedOnceTimer][ActiveController::ResizeEvent] 0ms
[t=00:06:05.402988][f=-000001] [SpringApp::MainEventHandler][SDL_WINDOWEVENT_SIZE_CHANGED][2]
``
Is it still an issue? These are all marked as merged or fixed:
Those 2 don't have anything to do with this issue:
This one: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 allows to mitigate the issue on the wayland compositor side, but changes are required on the wayland compositor side.
This: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915 was not sufficient at all, see detailed description in https://gitlab.gnome.org/GNOME/mutter/-/issues/2234
Looking at current mutter code, there was a recent commit merged in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3693 that bumps the buffers from 4K to 1MiB which should effectively resolve the issue in mutter and in Gnome. I see it's slotted for Gnome 47 release which is targeting 2024-09-14 so will land in distros sometime in autumn, and ofc never get to any stable LTS Linux distros like Ubuntu 24.04.
At the same time: that's just mutter and Gnome, I have no clue at what state all the other Linux wayland compositors are.
So, yeah, it's still a problem, resolution engine side would be to never block event processing.
After I've upgraded my system from Gnome 41 to 42 spring started crashing from time to time when loading games. I've managed to reproduce it to the points that when game is loading or map is being downloaded when I start to move my mouse a lot it crashes the process. When I don't move mouse at all, all is fine.
My current working theory is that when the game is being loaded/map is being downloaded spring doesn't process input events, that with combination of https://www.phoronix.com/scan.php?page=news_item&px=GNOME-42-Input-Rate introduced by upgrade, causes some event buffer (?) to overflow and crashing the process.