14:42 <arno11> Wizzup: @osso-games-startup: /usr/bin/osso-games-startup.launch is missing in daedalus.

14:47 <arno11> yeah, that's the problem. with it, drnoksnes starts normally

15:23 <Wizzup> ok, so another laucher issue

15:26 <arno11> btw i still have troubles with sdl display in picodrive. but it seems sdl1.2 is based on a different branch now in daedalus

15:27 <arno11> sdl is also buggy in smplayer btw

15:41 <arno11> hmm scratch that, even with the beowulf/chimaera sdl pkg, it doesn't work well

15:42 <arno11> afterall sdl1.2 is not supposed to work 'anymore'

21:05 <arno11> even if there are still few issues like qt5 apps slow to launch, overall daedalus perfs on n900 are quite good: able to compile picodrive and play drnoksnes @the same time with almost no slowdown (and no overclock) :D

21:06 <Wizzup> heh, seems like decent scheding

21:07 <arno11> :)

21:07 <Wizzup> scheduling

21:18 <arno11> ah, it says 'warning: video overlay is not hardware accelerated, not going to use it.' so that's why i can only use sdl window in pico

21:19 <arno11> so the problem is maybe only with new gpu stuff

21:23 <arno11> and btw when i load a qt5 app i see 'MESA: info: Loaded libpvr_dri_support.so' taking a while to load (around 5 sec)

21:39 <arno11> i wonder if qt5 troubles are 'noticeable' on d4

21:41 <arno11> *from a daedalus img

22:08 <arno11> oh, a troubleshooting option in qt5ct seems to solve the slowness issue: 'force raster surface'

22:11 <arno11> it makes a huge diff. need to check after a reboot

22:12 <arno11> it is even faster than my chimaera atm

22:15 <arno11> around 2-3 sec to launch a qt app, really good

22:16 <gnarface> hmm, suggests some missing hardware or driver feature, like layer opacity calculations that have to fall back on software otherwise?

22:26 <gnarface> or maybe just a gl/gles dichotomy issue?

22:26 <arno11> really don't know

22:28 <gnarface> just a guess; sounds like from what i infer "force raster surface" would do that primarily could benefit performance massively from what i've seen in the past on other hardware, is that it would avoid needing to do hardware transparency calculations on the fly

22:28 <gnarface> ...since i've noticed a particularly high cost when such calculations fall back on software mode, notably more than other types of rendering

22:29 <arno11> ah ok

22:32 <gnarface> but whether the hardware and/or driver is actually just missing that feature, or it merely needs a earlier opengl (or gles) version to access it, i couldn't say

22:33 <gnarface> similar issues have reared their heads on the pinephone in other distros though

22:45 <arno11> btw this qt5ct option doesn't cause any troubles for the moment excepting a white background in conversations main window

22:47 <gnarface> hmm, seems like a predictable side effect, but i wonder if it's inheriting that color from somewhere that you could change it to at least be black or something matching the rest of the UI

22:49 <arno11> in fact there are lot of options in qt5ct, i should have a look deeper

22:50 <gnarface> at least it didn't default to mauve :)

22:50 <arno11> yeah lol

22:58 <arno11> another noticeable good effect is the memory usage: it decreases a lot !

22:59 <gnarface> yea, that would make sense, as it would no longer have to keep multiple separate layers in memory, it'd just be flattening them all to one layer ahead of time

23:00 <gnarface> (this would in theory accrue a slightly higher CPU load but as we have seen elsewhere, not as high as the CPU load of having to constantly calculate transparency of multiple layers without the aid of a dedicated hardware feature in the GPU)

23:02 <arno11> yeah, at least now, things stay smooth even with 4 or 5 qt apps loaded

23:02 <arno11> included a heavy app like telegram-desktop

23:03 <arno11> not too bad for n900 :D

23:03 <gnarface> yea, for sure

23:08 <arno11> i'll open an issue tomorrow to keep a trace

23:11 <arno11> thx for details and clarifications btw

23:11 <gnarface> no problem... i wonder if qt5 stuff can still be built against gles2

23:12 <gnarface> google suggests the n900 can do gles2 in hardware, and also on the pinephones we've seen that stuff that migrated away from gles2 support took a severe performance hit

23:12 <gnarface> in theory that might get your performance back without losing rendering features

23:13 <gnarface> i think it depends though on whether the fundamental qt code has been changed too much to be able to use it

23:13 <gnarface> (specifics of this are over my head)

23:15 <gnarface> in theory also, you might just be able to force an earlier opengl version with a mesa environment variable, but so far i don't think we've seen anything coded in such a way that actually works

23:25 <arno11> ok, thx again. time to zzz