| arno11 | Wizzup: @osso-games-startup: /usr/bin/osso-games-startup.launch is missing in daedalus. | 15:42 |
|---|---|---|
| arno11 | yeah, that's the problem. with it, drnoksnes starts normally | 15:47 |
| Wizzup | ok, so another laucher issue | 16:23 |
| 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 | 16:26 |
| arno11 | sdl is also buggy in smplayer btw | 16:27 |
| arno11 | hmm scratch that, even with the beowulf/chimaera sdl pkg, it doesn't work well | 16:41 |
| arno11 | afterall sdl1.2 is not supposed to work 'anymore' | 16:42 |
| 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 | 22:05 |
| Wizzup | heh, seems like decent scheding | 22:06 |
| arno11 | :) | 22:07 |
| Wizzup | scheduling | 22:07 |
| 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 | 22:18 |
| arno11 | so the problem is maybe only with new gpu stuff | 22:19 |
| 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) | 22:23 |
| arno11 | i wonder if qt5 troubles are 'noticeable' on d4 | 22:39 |
| arno11 | *from a daedalus img | 22:41 |
| arno11 | oh, a troubleshooting option in qt5ct seems to solve the slowness issue: 'force raster surface' | 23:08 |
| arno11 | it makes a huge diff. need to check after a reboot | 23:11 |
| arno11 | it is even faster than my chimaera atm | 23:12 |
| arno11 | around 2-3 sec to launch a qt app, really good | 23:15 |
| gnarface | hmm, suggests some missing hardware or driver feature, like layer opacity calculations that have to fall back on software otherwise? | 23:16 |
| gnarface | or maybe just a gl/gles dichotomy issue? | 23:26 |
| arno11 | really don't know | 23:26 |
| 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 | 23: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 | 23:28 |
| arno11 | ah ok | 23:29 |
| 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 | 23:32 |
| gnarface | similar issues have reared their heads on the pinephone in other distros though | 23:33 |
| arno11 | btw this qt5ct option doesn't cause any troubles for the moment excepting a white background in conversations main window | 23:45 |
| 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 | 23:47 |
| arno11 | in fact there are lot of options in qt5ct, i should have a look deeper | 23:49 |
| gnarface | at least it didn't default to mauve :) | 23:50 |
| arno11 | yeah lol | 23:50 |
| arno11 | another noticeable good effect is the memory usage: it decreases a lot ! | 23:58 |
| 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:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!