| 87 | == Damage Latency == |
| 88 | This value represents the time it takes to: |
| 89 | * retrieve the pixels from the window |
| 90 | * compress them |
| 91 | * submit them to the network protocol layer |
| 92 | * pass them on to the operating system (which still has its own network buffers - though we do set the {{{NODELAY}}} socket flag, so this should be fairly small) |
| 93 | |
| 94 | This is the step that happens after we have waited for the batch delay above. |
| 95 | |
| 96 | |
| 97 | == Encoding Quality and Speed == |
| 98 | This value applies to the video encodings, {{{jpeg}}} and {{{webp}}} encodings. |
| 99 | When using a video encoder, we may also send the same area again using a lossless encoding as part of the "automatic lossless refresh". |
| 100 | |
| 101 | More information here: [/wiki/WindowRefresh#SpeedandQualityautotuning speed and quality auto tuning] |
| 102 | |
| 103 | |
| 104 | == Decoding Latency == |
| 105 | This figure represents the average time it takes for the client to decompress the screen updates it receives and update the window contents with it. |
| 106 | |
| 107 | |
| 108 | == Regions/s == |
| 109 | This is the number of screen updates per second. |
| 110 | Bear in mind that those updates may be very large or very small, and anything in between.. |
| 111 | |
| 112 | |
| 113 | == Pixels/region == |
| 114 | This is the average size of the screen updates the client is receiving. |
| 115 | |
| 116 | |
| 117 | == Pixels/s == |
| 118 | The total number of pixel updates displayed per second. |
| 119 | |