[aSpice Pro iOS/macOS] output lags behind one keypress in text mode menus

[b-]

I've noticed that the output seems to lag behind one frame in text mode menus when using Spice/qxl. For me this is most easily reproducible in Debian-style whiptail menus.

In case this bug is specific to my setup, I'm using Proxmox.

To reproduce: connect to a Debian VM via spice in text mode (ctrl+alt+f1 from a GUI is fine), and run, e.g., sudo dpkg-reconfigure console-setup. Try navigating with the arrow keys, and you'll notice that the menu is lagging behind by a keypress.

I've noticed this happens on both iOS and macOS, and it's definitely not exclusive to debian nor whiptail, but I haven't really pinpointed it any further than that. Oh, and it's pretty clearly (at least I think it is) a dirty-frame issue. Like, I'm pretty sure what's going on is that either the Spice server isn't properly notifying the client to update the frame, or the client isn't doing so properly when necessary.

I wonder if it might make sense (or even be possible) to put some sort of max age on a frame — I know Spice is trying to be efficient here, but I think it might make sense in the name of responsiveness to poll the server for something every 66.6 ms (15 fps) at least for a duration of time after keyboard input?

[OptimusPi]

Oh this is an interesting one! (I am not the developer I just have a similar setup and thought this was neat)

I tried to replicate this issue by using aSPICE Pro on iPadOS (iPad 8th gen)

• SPICE to PVE - no issues found
• SPICE to Ubuntu VM - issue found as described

The following pictures are of my PC screen and iPad screen held next to each other to prove the bug:

The iPad never updates until the next keystroke so it is off by one always as you mentioned.

P.S. The bug happens still on aSPICE Pro if I am controlling the vm with another SPICE client such as on windows 11. So typing it to a keypress is maybe not the best idea. Example scenario: I have a bluetooth keyboard to my pc, and I am only using the iPad as a "monitor" not to control it,. etc.

I think there must be something up with the double-buffering where it is not showing the next frame yet. And that is probably also causing a little bit of lag in other scenarios?

[iiordanov]

I can't reproduce this with libvirtd and aSPICE Pro running on a Mac. This must not be a bug on the client side if it's not reproducible with every environment, right?

https://photos.app.goo.gl/tQQmDA6eXPjmpc348

[b-]

Oddly enough it seems to be OS/application-dependent. I see you're trying it on a Grub menu -- try an Ubuntu or Debian text install disk.

I didn't try to reproduce this using libvirtd, but I'll be surprised if it's specific to Proxmox

[iiordanov]

I was trying to rule out a pervasive issue like double buffering which would be client side and should affect everything. It could be some specific versions of the spice the server not detecting and sending out changes immediately under certain circumstances (i.e. when it's heuristics fail to detect screen changes). I would imagine text based screens would be particularly affected because there are no hooks into an X server or the like that could hint to the server pixels are changing and it probably resorts to polling and diffing.

On Tue, Feb 7, 2023, 2:49 p.m. bri @.***> wrote:

Oddly enough it seems to be OS/application-dependent. I see you're trying it on a Grub menu -- try an Ubuntu or Debian text install disk.

I didn't try to reproduce this using libvirtd, but I'll be surprised if it's specific to Proxmox

— Reply to this email directly, view it on GitHub https://github.com/iiordanov/remote-desktop-clients/issues/424#issuecomment-1421352793, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK3EVZ6ZPYYABRN74HSKLTWWKRK3ANCNFSM6AAAAAAUTFP5HM . You are receiving this because you commented.Message ID: @.***>

[OptimusPi]

I understand if you cannot fix this, but I just wanted to reiterate:

I have shown an example where another SPICe client is updating right away and the iPad aSPICE Pro is not updating until the "next" keystroke as mentioned :) So that seems to me like it's not a PROXMOX issue at all, and only this client aSPICE Pro is affected in this scenario. It's so fast when I mash the keys up and down on the other spice client that it surely isn't polling.

Thanks for your insight though, I don't know too much about all this I suppose!

[iiordanov]

It could be a spice library version difference that is the cause of this. Let's leave the issue open and retest once I upgrade spice-gtk next.