xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 1 of Ticket #184, comment 3


Ignore:
Timestamp:
09/19/12 16:10:17 (8 years ago)
Author:
Antoine Martin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #184, comment 3

    initial v1  
    44* {{{draw}}}: there is a potential race here with mmap areas, which needs fixing, but this does not call anything UI related. The other codepath simply queues the packet for processing by another thread (the {{{draw_thread_loop}}} thread) (and it may also send a network packet in rare mmap cases when the window has disappeared - same codepath as ping)
    55This other thread (which was also introduced by the same changeset and is much more likely to be the real cause of the problem - your partial revert may just make it less likely or impossible to lose the race) only picks up items to draw from the queue and calls {{{window.draw_region}}} do decode and draw the frame. Assuming that you are using python2.x and gtk2.x (not doing so is very difficult!), this leads to 5 possibilities depending on the encoding used (which is not always the same as the encoding you specified... - which one did you specify?):
    6 * {{{paint_mmap}}} is called from the UI thread (and eventually calls {{{do_paint_rgb24}}})
     6* {{{paint_mmap}}} is called from the UI thread (grabs hold of the rgb24 mmapped data and calls {{{do_paint_rgb24}}})
    77* {{{paint_rgb24}}} decompresses the data with zlib then calls {{{do_paint_rgb24}}} from the UI thread
    88* {{{paint_x264}}} and {{{paint_vpx}}} use {{{paint_with_video_decoder}}} to decode the picture to rgb24 format then call {{{do_paint_rgb24}}} from the UI thread