Attachment 228 Details for Bug 1814 – Mail from Karl J. Runge

Mail from Karl J. Runge

cache.txt (text/plain), 2.89 KB, created by Peter Åstrand on 2007-01-11 10:02:21 CET

(hide)

Description:

Filename:

MIME Type:

Creator: Peter Åstrand

Created: 2007-01-11 10:02:21 CET

Size: 2.89 KB

patch

obsolete

>From runge@karlrunge.com Wed Jan 10 19:59:57 2007
>Date: Wed, 10 Jan 2007 13:58:50 EST
>From: Karl J. Runge <runge@karlrunge.com>
>To:  <vnc-tight-devel@lists.sourceforge.net>
>Subject: Re: RFB Caching technique
>
>Hi,
>
>On Tue, 31 Jan 2006, Vamsi Krishna wrote:
>>
>> We, at Novell, have started working on VNC and we want to contribute
>> to the performance improvements in VNC. We have come up with a
>> caching idea that we think is not yet present in tight vnc
>> implementation.
>>
>> The draft version of our proposal is available
>>
>> http://forge.novell.com/modules/xfcontent/private.php?reference_id=2729&content=/library/RFB%20Caching/rfbcaching.pdf
>
>I'm not sure if anyone is interested, but I have implemented an amusing
>hack that does client-side caching for x11vnc:
>
>        http://www.karlrunge.com/x11vnc/#faq-client-caching
>
>it is in the 0.8.4 development tarball.
>
>It is *really* inelegant, it simply creates a huge framebuffer where
>the top portion is the actual screen; the rest is used for caching pixel
>data (window backingstores and save-unders) that are swapped in and out
>via CopyRect.
>
>This is nice because it works with all existing VNC viewers, but with
>the cosmetic defect that you can scroll down and see the pixel cache
>(which really aids debugging :-)
>
>To tidy that up a libvncserver developer and I are thinking that a nice
>pseudo-encoding might be "rfbFBCrop" or something, that tells the viewer
>which rectangular region of the full FB it should display to the user.
>Besides window caching, this could enable double-buffering, offscreen
>rendering, etc.
>
>Well, my hack has very fast response, but it sucks up a huge amount of
>RAM (roughly 10X on both sides for nice response; this can be dialed
>down with the -ncache option but then fewer windows are kept "hot"),
>and so I am sure many will disapprove!
>
>However we tend to have a lot of RAM on both sides these days, I
>personally don't might using some for faster response while working
>remotely.  My tests show the speed/response is approaching that of NX
>for many activities.  x11vnc+Xvfb with this caching turned seems much
>faster to me than Xvnc (except for a few activities such as scrolling
>which are always difficult for poor little x11vnc).
>
>Anyway, it has only become barely usable in the past week and still has
>quite a few bugs.  If anyone is interested in helping me by testing it
>in their environment I certainly would appreciate that.
>
>Thanks,
>
>Karl
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>VNC-Tight-devel mailing list
>VNC-Tight-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
>

Actions: View

Attachments on bug 1814: 228