| freemangordon | arno11: does it make any difference if you start with LIBGL_ALWAYS_SOFTWARE=1 ? | 07:28 |
|---|---|---|
| freemangordon | or if you unset MESA_LOADER_DRIVER_OVERRIDE | 07:34 |
| freemangordon | both should result in PVR driver not being loaded | 07:34 |
| freemangordon | if it is still slow, then there is some issue in mesa | 07:34 |
| arno11 | freemangordon: yeah, still slow unfortunately | 09:08 |
| arno11 | *slow with a good u3, can't imagine how slow it is with class 10 or lower. | 09:25 |
| arno11 | but as soon as i set 'force raster widgets' in qt5ct troubleshooting tab, most qt5 apps take 2 sec to start (apart heavyweight stuff like tg ofc) | 09:28 |
| freemangordon | arno11: ok, good to hear it is not PVR related | 13:04 |
| freemangordon | so you think it is IO related? | 13:05 |
| freemangordon | maybe run some simple qt app through strace, to see what it is doing all that time | 13:06 |
| Wizzup | I think strace will reveal the problem honestly | 13:14 |
| Wizzup | if it's that long it's probably stuck in a syscall or so | 13:14 |
| Wizzup | ah lol I thought you said apitrace | 13:15 |
| Wizzup | yeah strace | 13:15 |
| Wizzup | I actually remember I had some similar issues recently at work, I think it was related to some timeout waiting for an IM | 13:20 |
| arno11 | freemangordon: i ran strace on osso_calculator with and without raster tweak. and diff the 2 resulting files: i see hundreds of 'readlink("/usr/share/themes/alpha", 0xbe8c4200, 1023) = -1 EINVAL (Invalid argument)' or similar | 14:08 |
| arno11 | *ATM, still checking the files | 14:10 |
| arno11 | is there any qt5 basic apps examples in Leste btw ? | 14:11 |
| buZz | you maybe able to grab any qt5 application from devuan/debian ? | 14:11 |
| buZz | might be* able | 14:11 |
| arno11 | i mean, very simple app to avoid huge strace output | 14:13 |
| arno11 | i also see hundreds of 'clock_gettime64(CLOCK_REALTIME, {tv_sec=1744717982, tv_nsec=834382533}) = 0 | 14:15 |
| arno11 | ' | 14:15 |
| arno11 | bbl | 14:35 |
| Wizzup | countdowntimer is pretty basic | 15:16 |
| uvos__ | simplest possible qt application is starting sphone with the qtloop module but no other modules | 16:28 |
| uvos__ | this just creates a QApplication and loop and dose nothing else | 16:29 |
| uvos__ | and yes this takes a very long time, even on d4 | 16:29 |
| uvos__ | the QApplication constructor takes forever | 16:29 |
| uvos__ | this is why sphone goes through quite a few contortions to avoid calling it unless its absolutely nesscary (ie we are the main sphone process, not one of its children or callers) | 16:32 |
| Wizzup | just to be clear, what arno is seeing is a regression | 16:34 |
| Wizzup | it's not a 'this takes a long time' problem, it is a 'this now takes much longer' problem | 16:35 |
| Wizzup | arno11: there is no issue for this right? | 16:39 |
| arno11 | Wizzup: absolutely no issue with qtloop and sphone | 16:46 |
| arno11 | uvos__: and yes that's a totally new issue in daedalus | 16:47 |
| sicelo | uvos__: BTW sphone may need some optimizations too. for example, I noticed that on every incoming call, one of the first things it does is to open the config file to check if an external application is configured to be run | 16:47 |
| sicelo | I think a simple optimization is to read that only at startup, not at every incoming call | 16:47 |
| arno11 | Wizzup: btw with strace, i see qt apps looking for powervr.ini (and failing ofc). weird, no ? | 16:50 |
| Wizzup | strace will show you a lot of things | 16:51 |
| Wizzup | not many of them matter necessarily | 16:52 |
| Wizzup | I'm making a log now too | 16:52 |
| arno11 | ok cool :) | 16:52 |
| Wizzup | My bet is either one some silly qt thing, the addition of our input module, or some mesa/gl interaction | 16:53 |
| arno11 | definitely not the input module btw (i deactivated it, no change with slowness) | 16:55 |
| Wizzup | how did you deactivate it? | 16:57 |
| arno11 | uninstalling qt-i-m iirc | 16:58 |
| Wizzup | 8925 16:47:02 openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/qt5/plugins/platformthemes/libqgtk3.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6 | 16:59 |
| Wizzup | this seems a bit strange | 16:59 |
| Wizzup | but maybe it's not used, will keep looking | 16:59 |
| arno11 | i saw it as well | 17:00 |
| Wizzup | ok, seems probably not used | 17:00 |
| arno11 | agree | 17:00 |
| arno11 | do you see lot of /usr/share/theme or icon stuff btw ? | 17:01 |
| Wizzup | still working on it | 17:02 |
| Wizzup | so far things look ok, but I am only three seconds in | 17:02 |
| Wizzup | (I used --timestamps) | 17:02 |
| Wizzup | so far it's just lib loading, setting up x conn, loading qt plugins | 17:02 |
| arno11 | ok (i used timestamps as well) | 17:03 |
| arno11 | /usr/share things seem to take a while and are not there if i use raster tweak | 17:04 |
| Wizzup | well this is just part of the gtk2 engine I think | 17:06 |
| arno11 | ok | 17:06 |
| Wizzup | I wonder if your tests just don't use the gtk2 theming engine | 17:08 |
| Wizzup | (the fast ones) | 17:08 |
| arno11 | i use gtk2 | 17:08 |
| Wizzup | so after about 10 seconds gtk seems to be loaded as well and fontconfig is done | 17:08 |
| Wizzup | right, but then why do you not see these files being loaded? | 17:09 |
| arno11 | misunderstanding: | 17:09 |
| arno11 | i don't see them when i use qt5ct tweak | 17:09 |
| Wizzup | that's what I mean | 17:10 |
| Wizzup | so I suspect that isn't actually using the gtk2 theming engine or something | 17:10 |
| Wizzup | there's a bunch more loading going on after gtk2 fonts, other gtk libs | 17:10 |
| Wizzup | so my countdowntimer started at 16:46:58 and started actually loading it's own config at 16:47:12 | 17:11 |
| Wizzup | 14 seconds of font / theme loading | 17:11 |
| Wizzup | (and libs) | 17:11 |
| arno11 | (100% sure qt5ct is using gtk2 theming) | 17:12 |
| arno11 | ok | 17:12 |
| Wizzup | Ah, yes, and after that qt starts loading more libs | 17:12 |
| arno11 | 14 sec, wow | 17:12 |
| Wizzup | then it loads/scans a million vlc plugins (countdowntimer has some audio through phonon )OD | 17:13 |
| Wizzup | phonon)* | 17:13 |
| Wizzup | then at 16:47:16 it seems to load maemo-egl integration | 17:15 |
| Wizzup | and then there's a waiting time for a while, polling on what I think is the first x client conn socket, and only after that it continues loading dri things | 17:16 |
| arno11 | what a mess for just a basic app lol | 17:17 |
| Wizzup | welcome to the desktop :) | 17:18 |
| Wizzup | so many things take a long time, but there's no one thing that's just stuck in some timeout | 17:19 |
| Wizzup | there must be something different in your setup wrt what the env vars are actually set to | 17:20 |
| Wizzup | in your qt5ct, do you have the style override set to maemo5, the qpa platform module set to maemo, and the im module set to him? | 17:21 |
| arno11 | style is maemo5, platform maemo and no change for im module | 17:22 |
| Wizzup | no change meaning it's set to 'him' ? | 17:23 |
| arno11 | no parameters | 17:23 |
| Wizzup | does the virtual keyboard work in qt apps for you with these settings? | 17:23 |
| Wizzup | say conversations, with the n900 keyboard closed | 17:23 |
| arno11 | let me check | 17:24 |
| Wizzup | (it might take a bit of time the first time, so be patient for the purpose of the test) | 17:24 |
| Wizzup | (you'll have to dsmetool -k the conversations binary) | 17:25 |
| Wizzup | well, depending on if you already got it set up qith qt5ct or not :)O | 17:25 |
| arno11 | argh...as usual...kids time when things are interesting... | 17:26 |
| arno11 | be back a bit later | 17:27 |
| Wizzup | np | 17:30 |
| sicelo | always interesting to see how maemo was ahead by many counts ... other projects today are still trying to solve issues Maemo long solved, e.g. https://gstconf.ubicast.tv/videos/embedded-audio-policies-made-easy-with-wireplumber/ | 18:54 |
| Wizzup | hopefully we can leverage wireplumber/pipewire at some point if they don't use too much ram | 18:55 |
| arno11 | hmm, can't get qt kbd working anymore. no troubles with gtk. will reboot and see | 20:39 |
| arno11 | Wizzup: yeah, got qt input and qt5ct stuff both working | 21:02 |
| arno11 | hm, in fact it is buggy... | 21:05 |
| Wizzup | arno11: when you say you got it both working, what does that mean, that in your previous tests it wasn't enabled, or? | 21:08 |
| sicelo | loxodonta | 21:16 |
| sicelo | -ECHAN, sorry | 21:16 |
| arno11 | Wizzup: in my previous tests, it was indeed disabled | 21:19 |
| arno11 | now i have both qt kb and qt5ct tweak working | 21:20 |
| arno11 | no bug, just a question of proper env var | 21:20 |
| arno11 | so the main issue is not qt input | 21:20 |
| arno11 | i mean, qt input or not, same results | 21:22 |
| Wizzup | so you're saying the startup times are the same, and the main different is disabling our mesa stack | 21:27 |
| Wizzup | difference* | 21:27 |
| Wizzup | although, I'm still surprised that your setup wouldn't load all the themes and fonts information, there have to be more environment variables at place here | 21:27 |
| Wizzup | s/place/play/ | 21:27 |
| arno11 | i'll pastebin my config in a bit | 21:32 |
| arno11 | https://paste.debian.net/hidden/632bdd38/ | 21:37 |
| arno11 | https://paste.debian.net/hidden/3abf5fba/ | 21:37 |
| arno11 | that's it | 21:37 |
| Wizzup | ok, so you're not using the gtk2 platform theme then, right? | 21:38 |
| Wizzup | I bet that this defaults to gtk2 for our default installs | 21:39 |
| arno11 | not sure: it uses gtk2 apparently, it needs qt5ct, then qt5ct set gtk2 | 21:41 |
| arno11 | *gtk2 platform | 21:43 |
| Wizzup | Looking at your qt5ct config, it seems to set the fonts and themes there, which might be why it's doing less searching for other fonts | 21:44 |
| Wizzup | and you're saying that when you remove 'force_raster_widgets' the startup times increase significantly? | 21:45 |
| arno11 | ok | 21:45 |
| arno11 | yes it increases a lot | 21:45 |
| arno11 | and things are fster than ever with the option activated | 21:46 |
| arno11 | *faster | 21:46 |
| Wizzup | I wonder if this is the same on chimaera or not | 22:07 |
| arno11 | good question, i didn t try | 22:09 |
| Wizzup | so setting it to two should have no effect | 22:09 |
| Wizzup | int forceRasterWidgets = settings.value("force_raster_widgets", Qt::PartiallyChecked).toInt(); | 22:09 |
| Wizzup | if(!m_isIgnored && forceRasterWidgets == Qt::Checked) | 22:09 |
| Wizzup | QCoreApplication::setAttribute(Qt::AA_ForceRasterWidgets, true); | 22:09 |
| Wizzup | else if(!m_isIgnored && forceRasterWidgets == Qt::Unchecked) | 22:09 |
| Wizzup | QCoreApplication::setAttribute(Qt::AA_ForceRasterWidgets, false); | 22:09 |
| Wizzup | I'll double check if this is the case, it depends on the enum values of Qt::Checked nad Qt::Unchecked | 22:10 |
| Wizzup | ah, ok, Qt::Checked = 2 | 22:10 |
| arno11 | hm, 2 is the correct value, 100% sure | 22:10 |
| Wizzup | so this becomes: | 22:11 |
| Wizzup | Make top-level widgets use pure raster surfaces, and do not support non-native GL-based child widgets. | 22:11 |
| arno11 | like if you use the ui to set it, it writes 2 in the qt5ct config file | 22:11 |
| arno11 | sorry, missed one of your msgs :P | 22:12 |
| Wizzup | 21:46 < arno11> and things are fster than ever with the option activated | 22:13 |
| Wizzup | 21:46 < arno11> *faster | 22:13 |
| Wizzup | if I am reading between the lines, can I conclude that say with the qt5ct setup with no raster option, it might be on par with chimaera, but setting this additional option makes things even faster? | 22:13 |
| arno11 | yeah | 22:14 |
| arno11 | the only issue i see is when i use the option on boot, it makes conversations chat windows buggy (looks like a window stack issue) | 22:18 |
| arno11 | if i set the option after boot, no issue | 22:18 |
| Wizzup | yes - the raster fallback breaks qml and many gl apps | 22:19 |
| arno11 | ah ok, i was pretty sure it was because of qml | 22:19 |
| Wizzup | qml makes use of transparency and opengl(es) to be fast | 22:20 |
| arno11 | ok | 22:20 |
| Wizzup | but this ultimately probably shows that the mesa or pvr driver have some overhead, but that is not totally unexpected | 22:20 |
| Wizzup | we'll have to decide how far to go with optimisations and such | 22:21 |
| arno11 | yes indeed | 22:21 |
| Wizzup | in any case, I am actually a bit more interested in why otherwise qt5ct makes thing sstart faster | 22:21 |
| arno11 | you should try it to see/feel the diff btw | 22:22 |
| Wizzup | I mean, I believe you, but I'm wondering why loading another platform module *first* makes things faster, you'd expected it to make things slower | 22:24 |
| arno11 | i see | 22:25 |
| Wizzup | or does it just not load our platform plugin? | 22:25 |
| arno11 | hmm, don't know | 22:30 |
| Wizzup | I have found it to be quit ehard to google for the QT_QPA_PLATFORMTHEME env var | 22:31 |
| Wizzup | everything just results in qt5ct | 22:31 |
| Wizzup | https://github.com/qt/qtbase/blob/750a0b5ef6f1698dcbb01337abc1d9dca0eb3612/src/gui/kernel/qguiapplication.cpp#L1533 | 22:36 |
| Wizzup | arno11: what is you set standard_dialogs=gtk2 to qmaemo5 | 22:42 |
| Wizzup | what if* | 22:42 |
| arno11 | sorry, bbiab | 22:42 |
| arno11 | if i set it to maemo and disable raster stuff, it becomes very slow again | 22:57 |
| arno11 | @google, yeah even AI is not really useful for that | 22:58 |
| Wizzup | arno11: ok, so your change is simply disabling the maemo style plugin | 23:09 |
| Wizzup | Now it makes more sense - qt5ct itself doesn't add anything here, but with your config it disables loading our style plugin (qmaemo5) | 23:10 |
| Wizzup | sorry, not style, but platformtheme | 23:11 |
| Wizzup | so this means that for example the file dialog helper is not present, I think | 23:12 |
| arno11 | file dialog helper ? | 23:12 |
| Wizzup | https://github.com/maemo-leste/qtstyleplugins/blob/master/src/plugins/platformthemes/maemo5/qmaemo5dialoghelpers.cpp#L161 | 23:14 |
| Wizzup | so in this case, I suspect that setting QT_STYLE_OVERRIDE=gtk2 QT_QPA_PLATFORM=maemo QT_QPA_PLATFORMTHEME=gtk2 QT_IM_MODULE=him might not have the slowdown | 23:15 |
| Wizzup | sorry, QT_STYLE_OVERRIDE should remain set to maemo5 | 23:15 |
| arno11 | ok, let me check | 23:15 |
| Wizzup | this way it starts in about 10 seconds for me | 23:16 |
| Wizzup | that is QT_STYLE_OVERRIDE=maemo5 QT_QPA_PLATFORM=maemo QT_QPA_PLATFORMTHEME=gtk2 QT_IM_MODULE=him countdowntimer | 23:17 |
| arno11 | 10 sec is very slow btw :P | 23:17 |
| Wizzup | that is cold start | 23:18 |
| Wizzup | warm start it's about 5 seconds | 23:18 |
| Wizzup | with QT_QPA_PLATFORMTHEME=maemo5 it's about 7-8 seconds | 23:18 |
| Wizzup | cold start meaning the files loaded are not yet in the linux vfs cache (in ram) | 23:18 |
| arno11 | yeah i know | 23:19 |
| arno11 | still very slow on my device compared to raster | 23:19 |
| arno11 | i.e cold start 3 sec for calculator, 1 sec warm start | 23:20 |
| arno11 | *with raster | 23:20 |
| Wizzup | ok, but let's leave raster out for the moment, because we determined that this is not related to daedalus vs chimaera | 23:20 |
| arno11 | sure | 23:20 |
| Wizzup | so you're saying that this 5-7 second startup time was better on chimaera? | 23:20 |
| arno11 | probably, yeah but hard to say | 23:22 |
| arno11 | i remember starting most qt apps in less than 5-6 sec | 23:22 |
| Wizzup | for me, calculator cold start time was 11-12 seconds, warm start up time 5-6 | 23:23 |
| arno11 | 11-12 sec cold start was a lot on chimaera | 23:23 |
| arno11 | iirc, 7-8 sec max | 23:24 |
| arno11 | but all of that probably highly depends on sd card | 23:25 |
| Wizzup | ok | 23:25 |
| Wizzup | I'm inclined to say we have work to do on our qt startup times, for which we should maybe file some issue(s), but at the same time I don't think it makes sense to consider this a blocker for daedalus, would you be inclined to agree? | 23:26 |
| arno11 | definitely not a blocker, technically. but i'm worried about users who wait for a good daedalus img | 23:35 |
| arno11 | but anyway there is a workaround | 23:35 |
| Wizzup | the workaround does disable functionality in both cases | 23:38 |
| arno11 | sorry but which perceptible functionality ? 3D accel ? | 23:39 |
| arno11 | *noticeable | 23:50 |
| arno11 | but afterall, basically, only calculator and qalendar are affected OOTB. should be maybe more problematic for OMP btw. | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!