| freemangordon | so, some results using a simple qtwidgets application (will post source code later on) https://paste.debian.net/1371450/ | 08:37 |
|---|---|---|
| freemangordon | Wizzup: ^^^ | 08:37 |
| freemangordon | maemo5 (or gtk2) style plugin is doing somethign very stupid | 08:37 |
| freemangordon | I wonder if it thinks theme has changed several times during stratup | 08:38 |
| Wizzup | freemangordon: good debugging | 10:32 |
| Wizzup | freemangordon: try with gtk style plugin as well perhaps? | 10:32 |
| arno11 | this libpvr weird behaviour in qt has been mentioned several times, and fyi happens 'outside' qt5 stuff like last picodrive (i.e using opengles scaling option) | 12:46 |
| arno11 | *with no any kind of tweaks | 12:47 |
| Wizzup | that is just loading libgl or libgles and init | 12:54 |
| arno11 | yep but why it is so long and why it sometimes load/unload it several times, that's the question | 12:56 |
| arno11 | this msg never appeared in chimaera afaik | 12:57 |
| arno11 | *when loading qt apps | 12:58 |
| kiva | Devuan installed to Nokia RX-72. I am not sure is wifi driver open source, but everything else should work with open-source drivers, even camera. So maybe Maemo Leste i686 someday? | 13:17 |
| kiva | or maybe better to have generic i586 with VESA drivers for starting point? | 13:18 |
| kiva | ...generic i586 for old netbooks PCs. | 13:28 |
| Wizzup | arno11: given fmg's example , 1300ms total seems acceptable | 13:41 |
| Wizzup | since that also has the pvr stuff in there | 13:41 |
| Wizzup | kiva: cute | 13:42 |
| arno11 | Wizzup: yeah indeed. i.e when i launch hamsterfiler, libpvr takes around 1-2 sec. the huge 'waiting' time happens before | 13:58 |
| arno11 | (around 10 sec before libpvr msg) | 13:58 |
| freemangordon | arno11: the times measured include everything | 17:53 |
| freemangordon | so,it has nothing to do with pvr | 17:53 |
| freemangordon | see the code https://paste.debian.net/1371530/ | 17:54 |
| freemangordon | the same code, but without using MainWindow takes 10ms | 17:55 |
| dsc_ | is this reproducable in a VM | 17:59 |
| dsc_ | probably not? | 18:00 |
| freemangordon | maybe, didn;t try | 18:00 |
| freemangordon | lemme do it\ | 18:00 |
| dsc_ | well, I'm using the VM a lot and I didnt notice such things, just fyi | 18:00 |
| dsc_ | was just wondering if I could quickly take a look | 18:00 |
| freemangordon | I doubt | 18:03 |
| freemangordon | this seem IO related | 18:03 |
| freemangordon | *seems | 18:04 |
| dsc_ | ok | 18:06 |
| freemangordon | hmm, either my n900 TS got broken or last upgrade broke it | 18:14 |
| * freemangordon boots to fremantle | 18:14 | |
| freemangordon | TS works properly in fremantle | 18:18 |
| freemangordon | I have a feeling that mce if kind of broken after last upgrade | 18:22 |
| freemangordon | ugh: | 18:37 |
| freemangordon | (process:4952): GLib-GObject-WARNING **: 19:37:05.340: g_object_get_is_valid_property: object class 'UpDevice' has no property named 'capacity-level' | 18:37 |
| freemangordon | mce: battery_upower: Percentage: 93 -> 92 | 18:37 |
| freemangordon | mce: battery_upower: Voltage: 3.915000 -> 3.810000 | 18:37 |
| freemangordon | mce: battery_upower: Capacity Level: � -> F`k�j�8�.���j | 18:37 |
| freemangordon | munmap_chunk(): invalid pointer | 18:37 |
| freemangordon | sicelo: ^^^ | 18:38 |
| freemangordon | fixed | 18:57 |
| arno11 | fremangordon: btw @TS, do you use emmc swap ? because not working TS for a while (10-60 sec) is a common issue with emmc + 6.6.y | 19:36 |
| freemangordon | arno11: it was mce restarting every couple of seconds | 19:37 |
| arno11 | oh | 19:37 |
| sicelo | freemangordon: thanks. | 19:44 |
| sicelo | although based on the error and your change, most likely libupower/glib had not been updated. capacity_level is already getting set to NULL in upowbat_init. | 19:47 |
| freemangordon | sure, but that does not change the fact the code has bug :) | 19:48 |
| sicelo | yes, that's why i appreciate the fix :-) | 19:49 |
| sicelo | out of curiosity, what was the TS doing? | 20:00 |
| freemangordon | mce restarting too many times seems to end up with TS disabled | 20:00 |
| sicelo | ah | 20:04 |
| freemangordon | Wizzup: it is gtk2 style that adds at least 1.5 seconds startup time | 20:08 |
| freemangordon | also, we spend lots of time parsing fontconfig | 20:09 |
| Wizzup | freemangordon: I think it might be because we have no ofnt config set | 20:14 |
| Wizzup | or does that make no sense? | 20:14 |
| freemangordon | what os ofnt config? | 20:14 |
| freemangordon | *what is | 20:14 |
| freemangordon | in /etc/fontconfig there are lots of xml files | 20:15 |
| freemangordon | I think those are parsed every time | 20:15 |
| freemangordon | hmm, in fontconfig, rescan is set to 30 seconds | 20:17 |
| Wizzup | this seems wrong | 20:27 |
| freemangordon | Wizzup: in any case, a simple QMainWindow application using 64 MiB seems a bit too much | 21:55 |
| freemangordon | with maemo5 style it is even worse: ~76MiB | 22:01 |
| dsc_ | can this be attributed to whatever maemo5, in turn, links against? | 22:01 |
| dsc_ | https://bpa.st/raw/SCJA | 22:03 |
| freemangordon | maemo5 style adds ~10MiB | 22:05 |
| freemangordon | event without it mem usage is still too high | 22:05 |
| freemangordon | I don;t have time now, but tomorrow will compile the same code on my a33, which is still on chimaera, to see what would be the memory usage there | 22:06 |
| freemangordon | 64MiB for as single window application... | 22:07 |
| freemangordon | *for a | 22:07 |
| dsc_ | https://bpa.st/raw/PTYA 80M, but I suspect many of those libs are already in memory/cached | 22:13 |
| Wizzup | yeah I would agree | 22:44 |
| Wizzup | and they'd be shared | 22:44 |
| Wizzup | freemangordon: also, even conversations doesn't use that much afaik, so that's also strange | 22:45 |
| Wizzup | freemangordon: are you stripping your build? | 22:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!