#2757 closed defect (fixed)
scroll paint corruption
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 4.0 |
Component: | core | Version: | 3.0.x |
Keywords: | Cc: |
Description
Trying to reproduce the memleak (#2730), I modified the simulate_console_user.py script and ran it in an xterm: windows.1.geometry=(1147, 229, 1423, 1408)
.
Semi reliably, the scroll paints end up corrupting the screen during the last part of the test (after ps -ef
).
Attachments (6)
Change History (14)
Changed 2 years ago by
Attachment: | scroll-corruption.png added |
---|
comment:1 Changed 2 years ago by
Status: | new → assigned |
---|
comment:2 Changed 2 years ago by
comment:3 Changed 2 years ago by
comment:4 Changed 2 years ago by
r26281 improves the cairo scroll paint code slightly.
Testing with the changes from r26277, the corruption seems to occur where the edge of the scroll bar on the left hand side aligns with the terminal output.
The scroll list ends up divided there (the page scrolls up, the scroll bar moves in the opposite direction).
Changed 2 years ago by
Attachment: | replay-scrolls.patch added |
---|
patch to save and replay scrolls later
Changed 2 years ago by
Attachment: | cairo_replayscroll2.py added |
---|
replay in two separate windows (original and copy)
Changed 2 years ago by
Attachment: | test_scrolling.py added |
---|
script to generate scrolling data from 2 pictures
comment:6 Changed 2 years ago by
Running the test script to generate scroll data:
$ test_scrolling.py ./scroll-27.png ./scroll-28.png 0, 28, 1339, 1181, 0, -26 0, 1235, 1339, 80, 0, -26 0, 1172, 1339, 37, 0, 26 0, 1237, 1339, 26, 0, 52
This matches the data captured from the client, and replaying the scroll changes produces an image that's wrong. Can be seen using:
$ cairo_replayscroll2.py ./scroll-28.png scroll-28.txt
The 3rd chunk is wrong and overlaps with data from the 2nd chunk (omitting horizontal coordinates which are always the same):
- 2nd chunk moves up by 26: 1235 / 80 -> rectangle from 1209 to 1289
- 3rd chunk moves down by 26: 1172 / 37 -> rectangle from 1198 to 1235
Overlaps should never occur!
comment:7 Changed 2 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in r26287. (also avoid harmless debug overflow in r26284)
Explanation: comment:6 is wrong. Overlaps can and do happen, we should not try to avoid them at all costs. The cost of splitting one large scroll region can be higher.
We have to keep track of which lines have been sent using 'scroll', that was also used to shortcut out and skip sending the same line again... but that was done badly: when we're in the loop because we're counting how many lines to include in a scroll region, we need to keep counting, not skip it.
Backport to v3.0.x in r26288.
For those stuck on v3.0.9 and earlier, you can start your server with:
XPRA_SCROLL_ENCODING=0 xpra start ...
To disable scroll encoding completely. The loss of performance with some workloads can be pretty significant.
comment:8 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2757
screenshot of the paint corruption