Provide an AppImage about gcompris-qt HOT 29 OPEN

I've send a MR on invent that adds a recipe for building GCompris AppImages using appimage-builder.

Please check: https://invent.kde.org/education/gcompris/-/merge_requests/38

from gcompris-qt.

Oh, actually "false alarm"... it's a known issue of mageia 7 (I need to unset QT_PLUGIN_PATH before running appimages with a different Qt version than system one... see https://bugs.mageia.org/show_bug.cgi?id=25038 ).

So, indeed it launches, and I could compare with our standalone package version.

-The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)
-The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react). I'm not sure what can be the cause for this delay.

Anyway, good to see progress on the topic :)

from gcompris-qt.

Started work at https://github.com/probonopd/GCompris-qt/blob/patch-1/.travis.yml
Build log at https://travis-ci.org/probonopd/GCompris-qt

from gcompris-qt.

Is a GitHub push -> Travis CI -> GitHub Releases workflow acceptable?

from gcompris-qt.

Still running into compilation issues, https://travis-ci.org/probonopd/GCompris-qt/builds/. Any help appreciated.

from gcompris-qt.

Update: Compilation is working now, AppImage gets built.

Build log:
https://travis-ci.org/probonopd/GCompris-qt

Remaining issue:
plugins/imageformats/libqsvg.so does not get deployed, caused by probonopd/linuxdeployqt#82.

from gcompris-qt.

Applying a workaround, https://transfer.sh/azDIU/GCompris-git.1f109eb-x86_64.AppImage is available for testing now. Seems to be working on openSUSE LEAP 42.2.

from gcompris-qt.

Hi,
I have some issue with gstreamer on a fresh ubuntu install: Inconsistency detected by ld.so: dl-tls.c: 74: _dl_next_tls_modid: Assertion `result <= GL(dl_tls_max_dtv_idx) + 1' failed!
Full log at: https://pastebin.com/gXQiSH0S

from gcompris-qt.

Thanks @petitlapin, interesting. Seems to be glibc related. More investigation is needed. Don't remember having seen this before.

Seems to have to do with

External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.

According to https://bbs.archlinux.org/viewtopic.php?id=8626,

This is a bug in glibc NPTL and gets triggered by libs that use TLS (Thread local storage) and load a lib via dlopen() calls that fail with unresolved symbols or library dependencies.

So we need to find the cause of the GStremer issues and fix them.

from gcompris-qt.

Hi,

sorry for delay.

I tested it on my daily machine with archlinux and on a KaOS virtual machine. The application runs but there are no sound:
(GCompris-git.1f109eb-x86_64.AppImage:2337): GStreamer-CRITICAL **: gst_element_add_pad: assertion 'GST_IS_PAD (pad)' failed
(GCompris-git.1f109eb-x86_64.AppImage:2337): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed
Also the translations are not built and shipped, to have them we need to add a few steps in the install:

• cmake .. -DCMAKE_INSTALL_PREFIX=/usr
• make getSvnTranslations
• cmake .. -DCMAKE_INSTALL_PREFIX=/usr (it needs to be run again so cmake knows about translations, we haven't found a solution to not having to not run cmake again)
• make BuildTranslations
• make -j$(nproc)
  ... (as before)

from gcompris-qt.

Thanks @petitlapin. Could you send a Pull Request please?

from gcompris-qt.

So possibly we need to bundle a private copy of gstreamer and its plugins. This may be some work.

from gcompris-qt.

AppImage for testing: https://invent.kde.org/alexislo/gcompris/-/jobs/65555/artifacts/raw/build/GCompris--x86_64.AppImage (expires in one week)

from gcompris-qt.

Thanks! I just answered on the MR on invent...

from gcompris-qt.

and... still some issues, when launching the test appimage here, it crashes directly:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

from gcompris-qt.

@Animtim which system are you on? Can you run it with strace?

from gcompris-qt.

@azubieta is it possible to unset QT_PLUGIN_PATH in .env?

The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)

Could this be due to path overlay code?

The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react).

Maybe somehow related to GPU accleration?

from gcompris-qt.

The appimage takes around twice more time to launch (~15s for the appimage, ~7sec for our standalone package)

Could this be due to path overlay code?

Not sure... maybe simply due to the fact that appimage (170.9 Mio) has "duplicates" libraries to load, while our standalone package (72Mio tar.xz) uses a few system libraries... Or, is appimage compressed somehow? (that would also require a little extra time to uncompress before loading?)

The appimage seems to be less "fluid": when clicking on an animal of the main menu categories selector, with our package it's instantly switching to it, while with the appimage it takes ~2s to react).

Maybe somehow related to GPU accleration?

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

from gcompris-qt.

Is appimage compressed somehow?

Yes. To see the difference, you can run --appimage-extract it and then run the extracted contents with ./squashfs-root/AppRun.

from gcompris-qt.

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

@azubieta can you reproduce this?

from gcompris-qt.

Is appimage compressed somehow?

Yes. To see the difference, you can run --appimage-extract it and then run the extracted contents with ./squashfs-root/AppRun.

Right, after extracting it is a little faster (~10s).

from gcompris-qt.

What kind of hardware are you running on (type of disk/SSD, CPU class)?

from gcompris-qt.

SSD drive, i5 cpu and internal GPU (HD 4000).

from gcompris-qt.

It feels indeed like an issue of GPU acceleration not working optimally with this appimage.

@azubieta can you reproduce this?

What I can notice is a bit of lag while loading the resources. The animation is smooth once it begins.

from gcompris-qt.

@azubieta is it possible to unset QT_PLUGIN_PATH in .env?

Yes.

Could this be due to path overlay code?

Maybe, let's test it.

from gcompris-qt.

Hi @azubieta did you have a chance to look into the performance topic yet? Thanks a lot.

from gcompris-qt.

About the performance topic (slow categories selection), we noticed it was (at least partly) related to some changes in our code that made loading activity categories slower. Then @petitlapin made some changes to optimize this part so it should be better, would be good to have a new appimage generated to test with latest changes.

from gcompris-qt.

I have made a MR on https://invent.kde.org/education/gcompris/-/merge_requests/38
but it's block due limitations of the infrastructure. I'll be sending a new one on Github soon.

from gcompris-qt.

What happened to the AppImage builds on https://invent.kde.org/alexislo/gcompris?

Reference:
AppImage/appimage.github.io#2330

from gcompris-qt.