-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [snip] > > 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? I think (3) is the definitely the most elegant solution, but I think it would be very intrusive and hard to implement. Are there any other reasons to re-code this networking stuff apart from the performance issue? So I guess I'll have a go at (1) when I get a chance.
Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAko17EUACgkQGK2zHPGK1rsOZwCcDNivNi3nARNZ7lz3CdJLWZm0 3tgAnisPq9SV9BJpOXxUnoyiJ8lxr2bE =diXo -----END PGP SIGNATURE----- _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
