[Spice-devel] Questions regarding Bug 62033 - Means to detect local-only

[Marc-André Lureau]

Hi

On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov <fedor.lyakhov at gmail.com> wrote:
> Hi everyone,
>
> I've made a bit of progress on this issue - "disable wallpaper" and "disable
> animations" somewhat work with Gnome3. The code is very simple:
>
> static void disable_animation()
> {
>     GSettings *desktop_settings =
> g_settings_new("org.gnome.desktop.interface");
>     g_settings_set_boolean(desktop_settings, "enable-animations", FALSE);
> }
>
> static void disable_wallpaper()
> {
>     GSettings *desktop_settings =
> g_settings_new("org.gnome.desktop.background");
>     g_settings_set_boolean(desktop_settings, "draw-background", FALSE);
> }
>
> But looks like this isn't enough. This implementation of disable_wallpaper
> actually freezes current background, it is still displayed just isn't scaled
> properly when e.g. resolution changes. I'd love some input from anyone with
> Gnome3 knowledge... What's expected behavior for Spice client in this case?

I think it is to have a solid background.

> Disable_animations seems to not changing things much - at least I still see
> some animations when opening menu or pressing Action button (top left
> corner).

That doesn't surprise me. If you think that some shell animations are
superflous, you may want to open a bug to GNOME.

>
> Another question is about --spice-disable-effects=font-smooth. While this
> can be changed via GSettings, I think it should be changed at X level,
> correct? Leading to subsequent question of supporting Wayland/Weston... Also
> I don't really see any use case for disabling anti-aliasing... Maybe
> configuring anti-aliasing level makes sense...

There is a Antialias = None setting in gnome-tweek-tool, so there must
be a corresponding GSettings key.

> Next question is about --spice-color-depth. Right now it supports
> Windows-specific values of 16 and 32, for Linux we'd need to support 16 and
> 24. I think this setting should be adjusted at X level, similarly to
> anti-aliasing.

Apparently, this is not possible with randr & gnome, and might need a
server restart. Also, I am not convinced this is the right approach,
it would be nice to have actual numbers for different use cases..

> There is another level of complexity: changing these settings takes
> permanent effect, and user doesn't have any means to reset them except
> dconf-editor (not user friendly at all).
> So looks like we'd need an '--spice-enable-effects' option (and by default,
> when enable/disable isn't set, use local-only detection - to be
> implemented). What do you think?

Perhaps, although in general, you use your VM either over WAN or
local, but not so much switching between the two all the time. And if
it is the case, there are chances you prefer to have the same look and
feel for both cases, so not doing any changes is probably ok.

> And finally, I haven't looked into KDE settings counterpart yet, but the
> question is already here - how should we bind to KDE settings API. Late
> binding via dlopen/dlsym - to be used only if KDE detected? Also,
> GSettings/Gnome3 support relies on GIO - and currently vdagent isn't
> dependent on this library (only on GLib). Should we not favor Gnome3 over
> KDE here and implement this feature symmetrically?

I would say it's fine to link with kde low-level counterpart. But in
general, favour DBus services usage if possible.

> I'm really sorry for so much questions about this tiny feature...
> Implementing DE-specifics within a client doesn't seem so easy or proper way
> for me now...

Imho, you could win much more performance gains by getting back to
"means to detect local only" and tuning spice settings itself
(disabling image compression etc), not tweaking the desktop settings,
but hey, do what you want! :)

-- 
Marc-André Lureau