On Sun, Jun 14, 2009 at 8:58 AM, Antoine Martin<[email protected]> wrote: > Just an idea I've had: when the full window needs to be refreshed, > waiting for the whole packet can take a while on a slow link (I am > testing on a fairly slow link at the moment). > Splitting the damage requests (or responses) would improve interactivity > quite a bit. The overall speed would be reduced because of the extra > packet headers, but to the user it would look like the refresh is > happening quicker (starts earlier). Especially if the window is an Xterm. > Looking at the code, the only problem I can see is that next_packet() > would need to be able to return multiple packets... Any other ideas?
There are a few ways we could do this: (1) where we would send a single redraw packet now, split that into several packets and queue them normally (what you say) (2) when we have a large damage rectangle to repair, pick some smaller piece of it and repair that instead (leaving the rest for the next go-round) The problem with this would be that if the whole window is changing fast (e.g., you're watching a movie), we might end up repairing the same sub-rectangle over and over, while the rest of the window got more and more stale. Or if we picked which sub-rectangle to update in some smarter way -- e.g., randomly -- then we might end up with a patchwork of different frames all displayed in the same window, and you would never get a consistent view. It's probably better to display a movie as coherent but low framerate than high framerate but incoherent. (3) make the network code smarter so that it can process draw requests in a streaming way as they come over the wire (it's already *receiving* the data incrementally, it just doesn't do anything with it until the whole packet has arrived) This would be a more elegant solution than (1), but it might be too nasty at the code level. We need to rework how the network code handles packets anyway, though, because right now our inability to quickly tell where the boundaries of bencoded packets are totally destroys our performance on high-speed links. I think the best approach would be to use strategy (1) to prototype this functionality and see how it works (it's not clear to me what the best way to break up rectangles is, how much it will actually help, etc., so it'd be good to play with a working model). Then decide whether to use strategy (1) or strategy (3) in practice. For implementing strategy (1), I wouldn't make next_packet return multiple packets; I'd make ServerSource.next_packet return one packet, and queue the rest onto its _ordinary_packets list. What do you think? -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
