disable desktop animations in desktop mode

[Antoine Martin]

As per ​GNOME Shell + Mutter See Changes For Tracking Software Rendering, VNC To Toggle Animations

Looks like a desktop specific dbus API, without any documentation that I could find.

[Antoine Martin]

Now instead it's part of the org.gnome.Mutter.ScreenCast/RemoteDestop API to allow any remote desktop or screen cast application to inhibit animations while its session is active.
Merged by Jonas Ådahl 2 months ago, yet I can't see this API as a dbus interface or gsettings, even on Fedora 32 with mutter 3.36.1, so I've asked: ​how to use.

Meanwhile:

$ gsettings list-recursively | grep -i animations
org.mate.interface gtk-enable-animations true
org.mate.interface enable-animations true
org.gnome.desktop.interface enable-animations true
com.deepin.wrap.gnome.desktop.interface enable-animations true

And this toggles it:

gsettings set org.gnome.desktop.interface enable-animations false

The only problem is that gsettings are global for the user and not per-session, and so this will affect other sessions until we reset it on exit.
Not a huge problem anyway since most desktop environments don't deal well with having multiple sessions for the same user simultaneously.

[Antoine Martin]

Implemented in r26293.

Problem is that we can't enable this new code by default because Gio.Settings can very easily segfault the whole process:

$ python3 -c "from gi.repository import Gio;Gio.Settings.new('hello')"

(process:490782): GLib-GIO-ERROR **: 18:19:01.514: Settings schema 'hello' is not installed
Trace/breakpoint trap (core dumped)

So for now, this needs to be enabled using:

XPRA_MODIFY_GSETTINGS=1 xpra start ...

(gdb) bt
#0  0x00007fffea5817b5 in _g_log_abort () at /lib64/libglib-2.0.so.0
#1  0x00007fffea582839 in g_log_default_handler () at /lib64/libglib-2.0.so.0
#2  0x00007fffea582a6b in g_logv () at /lib64/libglib-2.0.so.0
#3  0x00007fffea582c53 in g_log () at /lib64/libglib-2.0.so.0
#4  0x00007fffea32d3d9 in g_settings_set_property () at /lib64/libgio-2.0.so.0
#5  0x00007fffea4ad751 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#6  0x00007fffea4af338 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#7  0x00007fffea4af68d in g_object_new () at /lib64/libgobject-2.0.so.0
#8  0x00007fffea48faa8 in ffi_call_unix64 () at /lib64/libffi.so.6
#9  0x00007fffea48f2a4 in ffi_call () at /lib64/libffi.so.6
#10 0x00007fffea6b9c35 in pygi_invoke_c_callable (function_cache=function_cache@entry=0x555555709f50, state=state@entry=0x7fffffffcfd0, py_args=py_args@entry=('hello',), py_kwargs=py_kwargs@entry=0x0) at ../gi/pygi-invoke.c:690
#11 0x00007fffea6bb5e8 in _function_cache_invoke_real (py_kwargs=0x0, py_args=('hello',), state=0x7fffffffcfd0, function_cache=0x555555709f50) at ../gi/pygi-cache.c:930
#12 _constructor_cache_invoke_real (function_cache=0x555555709f50, state=0x7fffffffcfd0, py_args=('hello',), py_kwargs=0x0) at ../gi/pygi-cache.c:930
#13 0x00007fffea6bb76c in pygi_function_cache_invoke (function_cache=<optimized out>, py_args=<optimized out>, py_kwargs=<optimized out>) at ../gi/pygi-cache.c:863
#14 0x00007fffea6ba389 in pygi_callable_info_invoke (user_data=0x0, cache=<optimized out>, kwargs=<optimized out>, py_args=<optimized out>, info=<optimized out>) at ../gi/pygi-invoke.c:770
#15 _wrap_g_callable_info_invoke (self=<optimized out>, py_args=<optimized out>, kwargs=<optimized out>) at ../gi/pygi-invoke.c:770
#16 0x00007ffff7d61f6c in _Py_CheckRecursionLimit () at /lib64/libpython3.7m.so.1.0
#17 0x00007fffea85c710 in  ()
#18 0x00007fffea7e12f0 in  ()
#19 0x00007fffea6ac380 in _function_info_call () at ../gi/pygi-info.c:567
#20 0x0000000000000000 in  ()

This needs to be reported upstream..

[stdedos]

I know it's extra hustle for an upstream bug, but can't you do it in the same way as OpenGL probing is done (i.e. with a new process doing it and let it crash instead)? 😕

[Antoine Martin]

can't you do it in the same way as OpenGL probing is done

Better solution: r26294.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/2602