On Tue, 04 Oct 2011 15:47:48 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> The second thread is gated by send blocking... The problem is that simple send blocking is insufficient. As my article mentions, by the time you get a block you've already filled up way too much of the buffers along the way. It's not uncommon for multi-second buffers in DSL modems for instance. > > As part of these enhancements, the other thing I think we need to do is > implement a back buffer on the client. The idea would be to have a > viewer that never has to ask for updates from the server. If its window > becomes obscured, it continues to receive updates and draw them into its > back buffer, and when the window becomes visible again, it simply swaps > from back to front rather than requiring the server to re-send those > regions of the window. > The FLTK viewer already works like this. It keeps a copy of everything (in a platform specific way though) and can update its window without having to go back to the server. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
