#621 closed defect (fixed)
clipboard code should not compress in the UI thread, not assume zlib
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 0.14 |
Component: | core | Version: | 0.12.x |
Keywords: | Cc: |
Description
Difficulty is that the clipboard knows nothing about compression feature availability, as it is not directly tied to a client connection, at least on the server. When a new client comes in, we just hand over the clipboard instance...
Also, it does not have access to the per-client encoding thread, which would be the ideal place for slotting the compression work...
Change History (3)
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
- server encodes from the 'encode' thread as of r7049 - which means that clipboard can no longer arrive before the screen updates that go with it
- client encodes from the 'format' network thread as of r7051
Some ugly code remains in compressed_wrapper
calls, but that is now well isolated and can be dealt with later.
comment:3 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/621
Note: See
TracTickets for help on using
tickets.
Groundwork done in r7041, we no longer assume
zlib
.Remains:
self.damage_data_queue
(which should be renamed as compression queue or something more generic), or using a wrapper telling the network encode layer to do it