xpra icon
Bug tracker and wiki

Opened 7 months ago

Last modified 2 days ago

#2708 new defect

text mode rendering may become stale

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description

For example, if I use multi-caret selection in Sublime Text too quickly (select a text that exists multiple times on the document, press Ctrl+D repeatedly), doing it too fast might end up showing one of the scrolling frames, but the last frame will end up being stale for the text editing area except for part of the blinking cursor.

The workaround is to "wiggle" the scroll position with the mouse - but then that means I need to context switch between the keyboard and the mouse.

The other way, to click with the mouse or do some modification with the keyboard, while valid workarounds, do not fit said user scenario.

Change History (55)

comment:1 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Is this with or without opengl?

comment:2 Changed 7 months ago by stdedos

Oh, yeah, right - I forgot:

From a related invocation (not the same, that one is full of #2642)

"Xpra-Python3-x86_64_4.0-r25898\xpra_cmd" attach ssh://user@ip/2 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @hostname@/@server-display@" --opengl=no

2020-04-03 15:49:52,637 Xpra GTK3 client version 4.0-r25898 64-bit
2020-04-03 15:49:52,639  running on Microsoft Windows 10
2020-04-03 15:49:52,734 Warning: failed to import opencv:
2020-04-03 15:49:52,735  No module named 'cv2'
2020-04-03 15:49:52,735  webcam forwarding is disabled
2020-04-03 15:49:53,669 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-04-03 15:49:54,006 keyboard layout code 0x409
2020-04-03 15:49:54,007 identified as 'United States - English' : us
2020-04-03 15:49:54,438  keyboard settings: layout=us
2020-04-03 15:49:54,441  desktop size is 4160x1440 with 1 screen:
2020-04-03 15:49:54,442   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-04-03 15:49:54,442     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-04-03 15:49:54,442     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-04-03 15:49:59,073 enabled remote logging
2020-04-03 15:49:59,075 Xpra GTK3 X11 server version 3.0.8-r25767 64-bit
2020-04-03 15:49:59,076  running on Linux Ubuntu 16.04 xenial
2020-04-03 15:49:59,085 Attached to 172.16.57.121:22
2020-04-03 15:49:59,085  (press Control-C to detach)

2020-04-03 15:50:01,085 server is not responding, drawing spinners over the windows

So, no, client-side is disabled (which is hardcoded for me after #2669).

Last edited 7 months ago by stdedos (previous) (diff)

comment:3 Changed 7 months ago by Antoine Martin

If you can reproduce it, it would be useful to have a screenshot with:

XPRA_PAINT_BOX=1 xpra attach ...

This would tell us which screen paint event is getting messed up. (see ticket:760#comment:2 and xpra/client/paint_colors.py for the color mappings)
My guess is the scroll which is brown.

comment:4 in reply to:  3 Changed 7 months ago by stdedos

Replying to Antoine Martin:

If you can reproduce it, it would be useful to have a screenshot with:

XPRA_PAINT_BOX=1 xpra attach ...

This would tell us which screen paint event is getting messed up. (see ticket:760#comment:2 and xpra/client/paint_colors.py for the color mappings)
My guess is the scroll which is brown.

I think the problem will go away if I disconnect to re-attach with altered env.

comment:5 Changed 7 months ago by Antoine Martin

I think the problem will go away if I disconnect to re-attach with altered env.

You can also toggle this at runtime with the key shortcut #+Shift+F12, where # is usually Control (depends on the OS / DE).

comment:6 in reply to:  5 Changed 7 months ago by stdedos

Replying to Antoine Martin:

I think the problem will go away if I disconnect to re-attach with altered env.

You can also toggle this at runtime with the key shortcut #+Shift+F12, where # is usually Control (depends on the OS / DE).

Are you sure this is the correct hotkey / captured?

I know Shift+F11 is (because it iterferes with byobu:zoom command), but Ctrl+Shift+F12 (I don't care about Mac) does not seem to do anything (and/or it is forwarded down to the seamless apps).

Bonus question: Is there a "disable/enable-all-hotkeys" shortcut/menu option for xpra temporarily?

comment:7 Changed 6 months ago by Antoine Martin

Are you sure this is the correct hotkey / captured?

Sorry, on most platforms (but not on gnome-shell...) '#' means 'Alt+Shift' so you need to press Alt+Shift+F12.

The contrast was not great, so I've doubled it in r26160.

Bonus question: Is there a "disable/enable-all-hotkeys" shortcut/menu option for xpra temporarily?

Not yet, feel free to create a ticket for that.
We should probably just disable them when a grab is active, since that's normally used to send all input to the active window already.

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:8 in reply to:  7 Changed 6 months ago by stdedos

Replying to Antoine Martin:

Are you sure this is the correct hotkey / captured?

Sorry, on most platforms (but not on gnome-shell...) '#' means 'Alt+Shift' so you need to press Alt+Shift+F12.

Oh! Isn't that the thing that "restarts" something and can mess up window placement, workspace assignment etc?

The contrast was not great, so I've doubled it in r26160.

I am not sure where does that apply 😕

Bonus question: Is there a "disable/enable-all-hotkeys" shortcut/menu option for xpra temporarily?

Not yet, feel free to create a ticket for that.
We should probably just disable them when a grab is active, since that's normally used to send all input to the active window already.

#2739

comment:9 Changed 6 months ago by Antoine Martin

Oh! Isn't that the thing that "restarts" something and can mess up window placement, workspace assignment etc?

No, all it does it to toggle paint debugging.

I am not sure where does that apply 😕

Follow r26160 and you end up on browser/xpra/trunk/src/xpra/client/paint_colors.py

comment:10 in reply to:  9 Changed 6 months ago by stdedos

I am not sure where does that apply 😕

Follow r26160 and you end up on browser/xpra/trunk/src/xpra/client/paint_colors.py

I meant "I don't understand what it does" i.e. what does that change, how does it look before and after, etc, and which file it touches

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:11 Changed 6 months ago by Antoine Martin

I meant "I don't understand what it does" i.e. what does that change

The transparency of the paint box overlay. (see comment:3 for what that is)

how does it look before and after

Easier to see after. (less transparent)

and which file it touches

The file I linked to in comment:9.

comment:12 Changed 6 months ago by stdedos

  • and *not* which file it touches

My bad :-D

comment:13 Changed 6 months ago by stdedos

Okay, so the shortcut is a lot useful (if not a little bit disorienting).

I have a stale terminal, I activated rendering, and by moving the cursor down I see a partial brown box (I have nano open, which in that case it is missing nano header / shortcuts.

Also, during writing of this ticket, the terminal resized, and I see a lot of red inside the then-brown box.

Changed 6 months ago by stdedos

comment:14 Changed 6 months ago by stdedos

There are also a lot of artifacts

comment:15 Changed 6 months ago by stdedos


comment:16 Changed 6 months ago by Antoine Martin

There are also a lot of artifacts

Do you mean the small white squares mostly on the left hand side? (the coloured lines are obviously the paint debugging doing its thing)
If that's the case, I've got a hunch that running your server with XPRA_DELTA=0 xpra start ... may fix things.
In which case, I can try to fix things or just disable delta encoding for the next release.
Do you have any scaling enabled? Does it go away if you turn it off?

comment:17 in reply to:  16 Changed 6 months ago by stdedos

Replying to Antoine Martin:

There are also a lot of artifacts

Do you mean the small white squares mostly on the left hand side? (the coloured lines are obviously the paint debugging doing its thing)

Yes, them. For the sake of clarity, it's the nano cursor shadow (as I move down the lines)

If that's the case, I've got a hunch that running your server with XPRA_DELTA=0 xpra start ... may fix things.

Can I do that without starting my server from scratch? Can I upgrade it?

In which case, I can try to fix things or just disable delta encoding for the next release.
Do you have any scaling enabled? Does it go away if you turn it off?

Seamless client in my Windows does not need scaling, so I assume no.
Is the tray Scaling>None an accurate source of the currently applied scaling? If so, then it does not use scaling.

comment:18 Changed 6 months ago by Antoine Martin

Can I do that without starting my server from scratch? Can I upgrade it?

Yes:

XPRA_DELTA=0 xpra upgrade

Or another way would be to run the client with:

XPRA_DELTA_BUCKETS=0 xpra attach ...

(this should have the same effect: telling the user not to use delta regions)

Is the tray Scaling>None an accurate source of the currently applied scaling? If so, then it does not use scaling.

Should be, the surest way is the client output. ie:

desktop size is 3840x2160 with 1 screen:
  :1.0 (1016x572 mm - DPI: 96x95) workarea: 3840x2100 at 0x27
    SEK DP-2 (708x398 mm - DPI: 137x137)

Which should match the physical geometry unless scaling is applied.

comment:19 in reply to:  18 Changed 6 months ago by stdedos

(..)

Restarted, let's see

Which should match the physical geometry unless scaling is applied.

2020-04-22 18:51:43,276  keyboard settings: layout=us
2020-04-22 18:51:43,279  desktop size is 4160x1440 with 1 screen:
2020-04-22 18:51:43,280   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-04-22 18:51:43,280     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-04-22 18:51:43,280     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-04-22 18:51:52,977 enabled remote logging

It's just hard to find it on the specific client console due to the CSC spamming.

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:20 Changed 6 months ago by Antoine Martin

It's just hard to find it on the specific client console due to the CSC spamming.

CSC spamming?

comment:21 in reply to:  20 Changed 6 months ago by stdedos

Replying to Antoine Martin:

It's just hard to find it on the specific client console due to the CSC spamming.

CSC spamming?

#2642

comment:22 in reply to:  15 Changed 6 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

Replying to stdedos:


With drawing enabled beforehand:


comment:23 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Where is the corruption and what colour is it?

comment:24 in reply to:  23 Changed 6 months ago by stdedos

Replying to Antoine Martin:

Where is the corruption and what colour is it?

In my head, it sounds like a weird question.

There is no "corruption" - rather, there is lack of anything between the arrowed space

(which should be equivalent to the two lines above).

The colors involved are brown, red, and yellow - but as I said, the corruption is more like the void that exists, and not something partially/corruptedly drawn.

Also:

$ cat /proc/29922/cmdline 
/usr/bin/python3/usr/bin/xpraupgrade:20
$ tr '\0' '\n' < /proc/29922/environ | grep -i delta
XPRA_DELTA=0
Last edited 6 months ago by stdedos (previous) (diff)

comment:25 Changed 6 months ago by Antoine Martin

Was delta turned off as per comment:18?

The colors involved are brown, red, and yellow ..

brown=scroll, red=rgb32, yellow=png.

The prime suspect is scroll, please try:

XPRA_SCROLL_ENCODING=0 xpra attach ...

Or on the server:

XPRA_SCROLL_ENCODING=0 xpra start ...

comment:26 in reply to:  25 Changed 6 months ago by stdedos

Replying to Antoine Martin:

:/

$ XPRA_SCROLL_ENCODING=0 xpra upgrade :20
xpra main error:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/scripts/main.py", line 113, in main
    defaults = make_defaults_struct()
  File "/usr/lib/python3/dist-packages/xpra/scripts/config.py", line 1224, in make_defaults_struct
    return dict_to_validated_config(defaults, extras_defaults, extras_types, extras_validation)
  File "/usr/lib/python3/dist-packages/xpra/scripts/config.py", line 1230, in dict_to_validated_config
    validated = validate_config(d, extras_types=extras_types, extras_validation=extras_validation)
  File "/usr/lib/python3/dist-packages/xpra/scripts/config.py", line 1186, in validate_config
    v = parse_bool_or_number(int, k, v)
  File "/usr/lib/python3/dist-packages/xpra/scripts/config.py", line 1113, in parse_bool_or_number
    return parse_number(numtype, k, v, auto)
  File "/usr/lib/python3/dist-packages/xpra/scripts/config.py", line 1121, in parse_number
    return numtype(v)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

comment:27 Changed 6 months ago by Antoine Martin

TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

r26190 should fix that, you can apply it by hand and it will then tell you which config file option you have set is invalid (my guess is a duplicated value somewhere).

comment:28 in reply to:  27 Changed 6 months ago by stdedos

Replying to Antoine Martin:

TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

r26190 should fix that, you can apply it by hand and it will then tell you which config file option you have set is invalid (my guess is a duplicated value somewhere).

Oh yeah:

## 30_picture.conf
min-quality = 20
min-speed = 50
# http://xpra.org/trac/ticket/2617#comment:14
min-quality = 0
min-speed = 0

I thought it would override, not produce a list :/

comment:29 Changed 6 months ago by stdedos

Related to the above, one other issue would be:

When running programs like less (that switch to a "secondary/alternate" buffer) the update is not rendered.

Xpra renders the enter, and then the blinking cursor of less - but nothing of the file rendering:


comment:30 Changed 6 months ago by Antoine Martin

I think this may be the same bug as #2757, which means that turning off "scroll" encoding as per comment:25 would fix things.
That, or using opengl acceleration.

comment:31 Changed 6 months ago by stdedos

I cannot use OpenGL client-side because Intel #2669, and because of other issues (that give cores to the server, might be related to #2669)

Disabling scroll (client-side) seems to work.

So, is this the final solution for v3?

comment:32 Changed 6 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

Still not working:


Attached with set XPRA_SCROLL_ENCODING=0

"Xpra-Python3-x86_64_4.0-r26160\xpra_cmd" attach ssh://user@ip/20 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @hostname@/@server-display@" --opengl=no --bandwidth-limit=6Mbps

2020-05-08 09:22:46,671 Xpra GTK3 client version 4.0-r26160 64-bit
2020-05-08 09:22:46,673  running on Microsoft Windows 10
2020-05-08 09:22:46,755 Warning: failed to import opencv:
2020-05-08 09:22:46,756  No module named 'cv2'
2020-05-08 09:22:46,756  webcam forwarding is disabled
2020-05-08 09:22:47,501 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-05-08 09:22:47,771 keyboard layout code 0x409
2020-05-08 09:22:47,771 identified as 'United States - English' : us
2020-05-08 09:22:48,165  keyboard settings: layout=us
2020-05-08 09:22:48,173  desktop size is 4160x1440 with 1 screen:
2020-05-08 09:22:48,175   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-05-08 09:22:48,175     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-05-08 09:22:48,176     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-05-08 09:22:52,574 enabled remote logging
2020-05-08 09:22:52,576 Xpra GTK3 X11 server version 3.0.9-r26132 64-bit
2020-05-08 09:22:52,577  running on Linux Ubuntu 16.04 xenial
2020-05-08 09:22:52,586 Attached to ip:22
2020-05-08 09:22:52,587  (press Control-C to detach)


(xpra_cmd:19840): Pango-WARNING **: 09:22:53.146: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-05-08 09:22:54,175 UI thread is now blocked
2020-05-08 09:22:54,226 UI thread is running again, resuming
2020-05-08 09:23:03,955 server is not responding, drawing spinners over the windows
2020-05-08 09:23:05,723 server is OK again
2020-05-08 10:47:23,511 toggling debug on backing gtk3.CairoBacking(<cairo.ImageSurface object at 0x000000000799bd10>) for window 3
2020-05-08 11:11:51,745 toggling debug on backing gtk3.CairoBacking(<cairo.ImageSurface object at 0x000000000799b5b0>) for window 980
Last edited 6 months ago by stdedos (previous) (diff)

Changed 6 months ago by stdedos

Changed 6 months ago by stdedos

comment:33 Changed 6 months ago by Antoine Martin

Milestone: 4.04.1
Owner: changed from Antoine Martin to stdedos

Still not working:

Please try applying r26288 on your server (will be included in v3.0.10), or posting the paint box debugging screenshot. So we can see which encoding ended up painting wrong. (my money is still on "scroll")

That, or using opengl acceleration.

I was wrong about that, the bug was server side, turning off opengl did not help.

comment:34 Changed 6 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

The paint box is there - it's subtle enough to work with, but it might be hard to detect it. I take extra care to keep it on the screenshots.

comment:35 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

FYI: in v4, scroll is now just another encoding (#2810), so it can be configured out using the --encodings= switch.

Is this still a problem?

comment:36 Changed 4 months ago by stdedos

From time to time, yes.

The "generic" issue seems to be that scroll can totally miss an update, if it happens quickly enough.

The big fat offenders are full screen update - less in a terminal, that purple-and-gray-and-red TUI application used to display dialogs, input fields (most commonly seen in apt-get and friends, I see it routinely using needrestart https://github.com/liske/needrestart).
However, there are nice cases on missing a partial line draw (https://xpra.org/trac/ticket/2708#comment:24).

My new favorite set of released versions (latest 3.0.10 server and 4.0.2-I-don't-remember-which client) seem to have toned it down a bunch, but it's still there somewhere. Combined with the latency, and new tricks from my Client/VPN side, it's a total (ノಠ益ಠ)ノ彡┻━┻

Last edited 4 months ago by stdedos (previous) (diff)

comment:37 Changed 4 months ago by stdedos

I just saw it again: It happened when I switched tabs in gnome-terminal (one out of ... idk 100? 1000? 1000s? times that I'm switching tabs on a daily basis)

comment:38 Changed 4 weeks ago by Antoine Martin

Is this fixed by the latest update? (4.0.4 has multiple fixes that address issues similar to what you are describing)

comment:39 Changed 4 weeks ago by stdedos

Actually, Xpra-Python3-x86_64_4.1-r27519 seems more broken to me :/

Oh, and, by the way: set XPRA_SCROLL_ENCODING=0 is perma-active on my client. :-p

Last edited 3 weeks ago by stdedos (previous) (diff)

comment:40 Changed 3 weeks ago by Antoine Martin

Actually, Xpra-Python3-x86_64_4.1-r27519 seems more broken to me :/

If true, this is a data point, maybe XPRA_REPAINT_ALL=0 will help.

comment:41 Changed 3 weeks ago by stdedos

No, does not help. I still see e.g. the pre-less version of a terminal.

"Xpra-Python3-x86_64_4.1-r27631\xpra_cmd" attach ssh://user@ip/3 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @@/@server-display@" --headerbar=off --opengl=no --bandwidth-limit=6Mbps

XPRA_CUSTOM_TITLE_BAR=0
XPRA_EXECUTABLE=Xpra-Python3-x86_64_4.1-r27631
XPRA_REPAINT_ALL=0
XPRA_SCROLL_ENCODING=0

2020-10-08 10:26:11,402 Xpra GTK3 client version 4.1-r27631 64-bit
2020-10-08 10:26:11,404  running on Microsoft Windows 10
2020-10-08 10:26:12,353 GStreamer version 1.18.0 for Python 3.8.6 64-bit
2020-10-08 10:26:12,640 created named pipe 'Xpra\16840'
2020-10-08 10:26:12,859 keyboard layout code 0x409
2020-10-08 10:26:12,859 identified as 'United States - English' : us
2020-10-08 10:26:13,081  keyboard settings: layout=us
2020-10-08 10:26:13,083  desktop size is 4160x1440 with 1 screen:
2020-10-08 10:26:13,084   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-10-08 10:26:13,084     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860 at 0x534
2020-10-08 10:26:13,084     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400 at 1600x0
2020-10-08 10:26:16,239 enabled remote logging
2020-10-08 10:26:16,242 Xpra GTK3 X11 server version 3.0.12-r27620 64-bit
2020-10-08 10:26:16,243  running on Linux Ubuntu 16.04 xenial
2020-10-08 10:26:16,257 Attached to ip:22
2020-10-08 10:26:16,260  (press Control-C to detach)


(xpra_cmd:16840): Pango-WARNING **: 10:26:16.646: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-10-08 10:26:17,675 UI thread is now blocked
2020-10-08 10:26:17,749 UI thread is running again, resuming
2020-10-08 10:26:17,773 Warning: static gravity is not handled
2020-10-08 11:02:17,938 downloaded 8 bytes to temporary file:
2020-10-08 11:02:17,939  '\Downloads\.r'
2020-10-08 11:02:20,928 unknown string message: 0xc238 / 0x0 / 0x0
2020-10-08 11:02:31,531 downloaded 8 bytes to temporary file:
2020-10-08 11:02:31,571  '\Downloads\.r'
2020-10-08 12:12:38,577 Warning: failed to set clipboard data
2020-10-08 12:12:38,581  OpenClipboard: too many failed attempts, giving up
2020-10-08 13:43:31,874 server is not responding, drawing spinners over the windows
2020-10-08 13:43:33,134 server is OK again
2020-10-08 13:43:56,892 server is not responding, drawing spinners over the windows
2020-10-08 13:43:57,904 server is OK again
Last edited 3 weeks ago by stdedos (previous) (diff)

comment:42 Changed 3 weeks ago by Antoine Martin

No, does not help

Ooops, should have been XPRA_REPAINT_ALL=1.
Fingers crossed.

comment:43 Changed 3 weeks ago by stdedos

It does help at least with a different issue, that used to look like this

Changed 3 weeks ago by stdedos

comment:44 Changed 9 days ago by stdedos

The Sublime scrolling issue might take forever to replicate, but so far, so good.

comment:45 in reply to:  44 Changed 9 days ago by stdedos

Replying to stdedos:

The Sublime scrolling issue might take forever to replicate, but so far, so good.

Well ... scratch that. I just saw it briefly in JetBrains 😕

Last edited 9 days ago by stdedos (previous) (diff)

comment:46 Changed 2 days ago by stdedos

... and now in Sublime. It may mask it enough, but not totally.

Note: See TracTickets for help on using tickets.