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 Version 2 and Version 3 of WindowRefresh


Ignore:
Timestamp:
01/15/13 14:22:59 (8 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WindowRefresh

    v2 v3  
    1616  * {{{DamageBatchConfig}}}: the structure which encapsulates all the configuration and historical values related to a batch delay.
    1717  * {{{WindowPerformanceStatistics}}}: per-window statistics: performance of the encoding/decoding, amount of frames and pixels in flight, etc. Again, the {{{get_factors}}} method rreturns a guesstimate of how the batch delay should ne agjusted for the given parameters ("pixel_count" and current "batch delay")
     18* [/browser/trunk/src/xpra/batch_delay_calculator.py batch_delay_calculator.py]: this class is where we used the factors obtained by {{{get_factors}}} above to tune the various attributes.
    1819
    1920[[BR]]
     
    2324
    2425== Background on damage request processing ==
     26Step by step (and oversimplified - so check the code for details) of the critical damage code path:
     27* an X11 client application running against the xpra display updates something on one of its windows, or creates a new window, resizes it, etc. It notifies the X11 server that something needs to be redrawn, changed or updated.
     28* xpra, working as a compositing window manager, receives a notification that something needs updating/changing.
     29* this {{{Damage}}} event is forwarded through various classes ({{{CompositeHelper}}}, {{{WindowModel}}}, .. and eventually ends up in the server's {{{damage}}} method - often as a {{{Damage}}} event directly, or in other cases we synthesize one to force the client to (re-)draw the window.
     30* then for each client connected, we call {{{damage}}} on its {{{ServerSource}}} (see above)
     31* then this damage event is forwarded to the {{{WindowSource}}} for the given window (creating one if needed)
     32* then we either add this event to the current list of delayed regions (which will expire after "batch delay"), we create a new delayed region, or if things are not congested at all we just process it immediately
     33* {{{process_damage_region}}} (called when the timer expires - or directly) will grab the window's pixels and queue a request to call "make a data packet" from it. This is done so that we minimize the amount of work done in the critical UI thread, another thread will pick items off this queue.
     34
     35The damage thread will pick items from this queue, decide what compression to use, compress the pixels and make a data packet then queue this packet for sending. Note that the queue is in {{{ServerSource}}} and it is shared between all the windows..
     36
     37Things not covered here:
     38* auto-refresh
     39* choosing between a full frame or many smaller regions
     40* various tunables
     41* callbacks recording performance statistics
     42* callbacks between {{{ServerSource}}} and {{{WindowSource}}}
     43* error handling
     44* cancelling requests
     45* client encoding options
     46* mmap
     47
     48
     49== The Factors ==
    2550
    2651
     
    2853
    2954
     55