<freemangordon>
arno11: does it make any difference if you start with LIBGL_ALWAYS_SOFTWARE=1 ?
<freemangordon>
or if you unset MESA_LOADER_DRIVER_OVERRIDE
<freemangordon>
both should result in PVR driver not being loaded
<freemangordon>
if it is still slow, then there is some issue in mesa
_fab has quit [Quit: _fab]
_fab has joined #maemo-leste
Anasko has joined #maemo-leste
lul4 has quit [Quit: had to jack off]
_fab has quit [Ping timeout: 252 seconds]
_fab has joined #maemo-leste
System_Error has quit [Ping timeout: 264 seconds]
_fab has quit [Remote host closed the connection]
arno11 has joined #maemo-leste
_fab has joined #maemo-leste
<arno11>
freemangordon: yeah, still slow unfortunately
System_Error has joined #maemo-leste
<arno11>
*slow with a good u3, can't imagine how slow it is with class 10 or lower.
<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)
joerg has quit [Ping timeout: 245 seconds]
joerg has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
mkfx has joined #maemo-leste
<freemangordon>
arno11: ok, good to hear it is not PVR related
<freemangordon>
so you think it is IO related?
<freemangordon>
maybe run some simple qt app through strace, to see what it is doing all that time
<Wizzup>
I think strace will reveal the problem honestly
<Wizzup>
if it's that long it's probably stuck in a syscall or so
<Wizzup>
ah lol I thought you said apitrace
<Wizzup>
yeah strace
<Wizzup>
I actually remember I had some similar issues recently at work, I think it was related to some timeout waiting for an IM
arno11 has joined #maemo-leste
<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
<arno11>
*ATM, still checking the files
<arno11>
is there any qt5 basic apps examples in Leste btw ?
<buZz>
you maybe able to grab any qt5 application from devuan/debian ?
<buZz>
might be* able
<arno11>
i mean, very simple app to avoid huge strace output
<arno11>
i also see hundreds of 'clock_gettime64(CLOCK_REALTIME, {tv_sec=1744717982, tv_nsec=834382533}) = 0
<arno11>
'
<arno11>
bbl
arno11 has left #maemo-leste [#maemo-leste]
mkfx has left #maemo-leste [Error from remote client]
pere has quit [Ping timeout: 276 seconds]
<Wizzup>
countdowntimer is pretty basic
_fab has quit [Quit: _fab]
uvos__ has joined #maemo-leste
<uvos__>
simplest possible qt application is starting sphone with the qtloop module but no other modules
<uvos__>
this just creates a QApplication and loop and dose nothing else
<uvos__>
and yes this takes a very long time, even on d4
<uvos__>
the QApplication constructor takes forever
Danct12 has quit [Quit: WeeChat 4.6.1]
ungeskriptet has quit [Ping timeout: 248 seconds]
<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)
<Wizzup>
just to be clear, what arno is seeing is a regression
<Wizzup>
it's not a 'this takes a long time' problem, it is a 'this now takes much longer' problem
<Wizzup>
arno11: there is no issue for this right?
arno11 has joined #maemo-leste
<arno11>
Wizzup: absolutely no issue with qtloop and sphone
<arno11>
uvos__: and yes that's a totally new issue in daedalus
<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
<sicelo>
I think a simple optimization is to read that only at startup, not at every incoming call
<arno11>
Wizzup: btw with strace, i see qt apps looking for powervr.ini (and failing ofc). weird, no ?
<Wizzup>
strace will show you a lot of things
<Wizzup>
not many of them matter necessarily
<Wizzup>
I'm making a log now too
<arno11>
ok cool :)
<Wizzup>
My bet is either one some silly qt thing, the addition of our input module, or some mesa/gl interaction
<arno11>
definitely not the input module btw (i deactivated it, no change with slowness)
<Wizzup>
but maybe it's not used, will keep looking
<arno11>
i saw it as well
<Wizzup>
ok, seems probably not used
<arno11>
agree
<arno11>
do you see lot of /usr/share/theme or icon stuff btw ?
<Wizzup>
still working on it
<Wizzup>
so far things look ok, but I am only three seconds in
<Wizzup>
(I used --timestamps)
<Wizzup>
so far it's just lib loading, setting up x conn, loading qt plugins
<arno11>
ok (i used timestamps as well)
<arno11>
/usr/share things seem to take a while and are not there if i use raster tweak
<Wizzup>
well this is just part of the gtk2 engine I think
<arno11>
ok
<Wizzup>
I wonder if your tests just don't use the gtk2 theming engine
<Wizzup>
(the fast ones)
<arno11>
i use gtk2
<Wizzup>
so after about 10 seconds gtk seems to be loaded as well and fontconfig is done
<Wizzup>
right, but then why do you not see these files being loaded?
<arno11>
misunderstanding:
<arno11>
i don't see them when i use qt5ct tweak
<Wizzup>
that's what I mean
<Wizzup>
so I suspect that isn't actually using the gtk2 theming engine or something
<Wizzup>
there's a bunch more loading going on after gtk2 fonts, other gtk libs
<Wizzup>
so my countdowntimer started at 16:46:58 and started actually loading it's own config at 16:47:12
<Wizzup>
14 seconds of font / theme loading
<Wizzup>
(and libs)
<arno11>
(100% sure qt5ct is using gtk2 theming)
<arno11>
ok
<Wizzup>
Ah, yes, and after that qt starts loading more libs
<arno11>
14 sec, wow
<Wizzup>
then it loads/scans a million vlc plugins (countdowntimer has some audio through phonon )OD
<Wizzup>
phonon)*
<Wizzup>
then at 16:47:16 it seems to load maemo-egl integration
<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
<arno11>
what a mess for just a basic app lol
<Wizzup>
welcome to the desktop :)
<Wizzup>
so many things take a long time, but there's no one thing that's just stuck in some timeout
<Wizzup>
there must be something different in your setup wrt what the env vars are actually set to
<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?
<arno11>
style is maemo5, platform maemo and no change for im module
<Wizzup>
no change meaning it's set to 'him' ?
<arno11>
no parameters
<Wizzup>
does the virtual keyboard work in qt apps for you with these settings?
<Wizzup>
say conversations, with the n900 keyboard closed
<arno11>
let me check
<Wizzup>
(it might take a bit of time the first time, so be patient for the purpose of the test)
<Wizzup>
(you'll have to dsmetool -k the conversations binary)
<Wizzup>
well, depending on if you already got it set up qith qt5ct or not :)O
<arno11>
argh...as usual...kids time when things are interesting...
<Wizzup>
hopefully we can leverage wireplumber/pipewire at some point if they don't use too much ram
Pali has joined #maemo-leste
akossh has joined #maemo-leste
<arno11>
hmm, can't get qt kbd working anymore. no troubles with gtk. will reboot and see
arno11 has left #maemo-leste [#maemo-leste]
_fab has quit [Quit: _fab]
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: yeah, got qt input and qt5ct stuff both working
mkfx has joined #maemo-leste
<arno11>
hm, in fact it is buggy...
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
arno11: when you say you got it both working, what does that mean, that in your previous tests it wasn't enabled, or?
<sicelo>
loxodonta
<sicelo>
-ECHAN, sorry
arno11 has joined #maemo-leste
<arno11>
Wizzup: in my previous tests, it was indeed disabled
<arno11>
now i have both qt kb and qt5ct tweak working
<arno11>
no bug, just a question of proper env var
<arno11>
so the main issue is not qt input
<arno11>
i mean, qt input or not, same results
<Wizzup>
so you're saying the startup times are the same, and the main different is disabling our mesa stack
<Wizzup>
difference*
<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
<Wizzup>
I'll double check if this is the case, it depends on the enum values of Qt::Checked nad Qt::Unchecked
<Wizzup>
ah, ok, Qt::Checked = 2
<arno11>
hm, 2 is the correct value, 100% sure
<Wizzup>
so this becomes:
<Wizzup>
Make top-level widgets use pure raster surfaces, and do not support non-native GL-based child widgets.
<arno11>
like if you use the ui to set it, it writes 2 in the qt5ct config file
<arno11>
sorry, missed one of your msgs :P
<Wizzup>
21:46 < arno11> and things are fster than ever with the option activated
<Wizzup>
21:46 < arno11> *faster
<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?
<arno11>
yeah
akossh has quit [Quit: Leaving.]
<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)
<arno11>
if i set the option after boot, no issue
<Wizzup>
yes - the raster fallback breaks qml and many gl apps
<arno11>
ah ok, i was pretty sure it was because of qml
<Wizzup>
qml makes use of transparency and opengl(es) to be fast
<arno11>
ok
<Wizzup>
but this ultimately probably shows that the mesa or pvr driver have some overhead, but that is not totally unexpected
<Wizzup>
we'll have to decide how far to go with optimisations and such
<arno11>
yes indeed
<Wizzup>
in any case, I am actually a bit more interested in why otherwise qt5ct makes thing sstart faster
<arno11>
you should try it to see/feel the diff btw
<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
<arno11>
i see
<Wizzup>
or does it just not load our platform plugin?
Livio has quit [Ping timeout: 264 seconds]
<arno11>
hmm, don't know
<Wizzup>
I have found it to be quit ehard to google for the QT_QPA_PLATFORMTHEME env var
<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
<Wizzup>
sorry, QT_STYLE_OVERRIDE should remain set to maemo5
<arno11>
ok, let me check
<Wizzup>
this way it starts in about 10 seconds for me
<Wizzup>
that is QT_STYLE_OVERRIDE=maemo5 QT_QPA_PLATFORM=maemo QT_QPA_PLATFORMTHEME=gtk2 QT_IM_MODULE=him countdowntimer
<arno11>
10 sec is very slow btw :P
<Wizzup>
that is cold start
<Wizzup>
warm start it's about 5 seconds
<Wizzup>
with QT_QPA_PLATFORMTHEME=maemo5 it's about 7-8 seconds
<Wizzup>
cold start meaning the files loaded are not yet in the linux vfs cache (in ram)
<arno11>
yeah i know
<arno11>
still very slow on my device compared to raster
<Wizzup>
ok, but let's leave raster out for the moment, because we determined that this is not related to daedalus vs chimaera
<arno11>
sure
<Wizzup>
so you're saying that this 5-7 second startup time was better on chimaera?
<arno11>
probably, yeah but hard to say
<arno11>
i remember starting most qt apps in less than 5-6 sec
<Wizzup>
for me, calculator cold start time was 11-12 seconds, warm start up time 5-6
<arno11>
11-12 sec cold start was a lot on chimaera
<arno11>
iirc, 7-8 sec max
<arno11>
but all of that probably highly depends on sd card
<Wizzup>
ok
<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?
<arno11>
definitely not a blocker, technically. but i'm worried about users who wait for a good daedalus img
<arno11>
but anyway there is a workaround
<Wizzup>
the workaround does disable functionality in both cases
<arno11>
sorry but which perceptible functionality ? 3D accel ?
<arno11>
*noticeable
<arno11>
but afterall, basically, only calculator and qalendar are affected OOTB. should be maybe more problematic for OMP btw.
arno11 has left #maemo-leste [#maemo-leste]
n900 has quit [Ping timeout: 268 seconds]
lul4 has joined #maemo-leste
Pali has quit [Quit: Pali]
n900 has joined #maemo-leste
<Wizzup>
arno11: 3d and as stated, the platform theme being maemo, which means certain dialogs will be off
mkfx has left #maemo-leste [Disconnected: Replaced by new connection]