On Wed, 13 Jul 2011 06:19:16 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> On 7/13/11 3:49 AM, Pierre Ossman wrote: > >> (2) Automatic Lossless Refresh (ALR) -- This feature is similar to LR > > > > I'd like to believe this could be done in a way where it could always > > be turned on, or at least on by default. I didn't get the impression > > that any of the problems you listed would prevent that? > > I disagree. For starters, the ALR timeout really needs to be something > that the user can configure, because different applications and network > environments may call for a different value there. Well, I'm not convinced that we can't automate this to a large degree. But we'll cross that bridge when we get to it. I have no problem with first versions requiring manual knobs. > > It might also be worth considering updating parts of the screen, and > > not all of it. After all, we're sending a better quality version of > > what's already on the screen, so there should be no risk of tearing > > caused by partial updates. This would also mitigate issues with the > > lossless update introducing latency because it being much larger than > > the lossy one. > > It already does this. Only the tiles that were previously sent with > lossy compression are re-sent during an ALR. Yes, but I meant that we could also split those parts into smaller pieces. E.g. say that 50% of the screen is "lossy". But that's a lot of data, so we only send 10% ALR in each update. Eventually all of the screen will have been updated, but if any "real" updates were needed, we wouldn't have a big queue of ALR to wait for first. > >> CU takes advantage of the RFB Continuous > >> Updates extension (this is a registered extension, not something we made > >> up ourselves.) > > > > Interesting. Do you have some reference documentation for this? There > > are a lot of annoying corner cases with regard to synchronising with > > other RFB messages. I'm interested in seeing how that is dealt with. > > There are also the flow/congestion control issues. > > Actually no, and I searched long and hard for it. It appears in the RFB > protocol documentation: > > http://tigervnc.sourceforge.net/cgi-bin/rfbproto > > The only place I've actually seen it implemented, however, is in Paul > Donohue's Java VNC Viewer code. It appears to have originally been > designed such that you could drag-select a region of the window in which > a video was playing, and the server would start sending continuous > updates for that region until you disabled the feature. > Hmm.. I remember looking at this. Unfortunately, I seem to recall that it was more or less useless. It didn't solve the existing synchronisation issues of the protocol, and it introduced new ones. I don't think that variant can server any purpose other than as a proof of concept. > It's not that the deferred update timer is necessarily a bad idea. I > think it may just need some re-thinking. Agreed. I think there might even be a bug for it. It doesn't work very well at all right now... > > I'm familiar with OpenMP, but I don't see it as really being a good > solution for this. When you say "most compilers", of course the ones > I'm currently using to build TigerVNC aren't included in that, and we > really need more control over the threads. Since the implementation in > TurboVNC is quite stable at this point, I can just borrow a lot of the > logic from there. Wikipedia indicates that both Microsofts compilers as well as gcc supports it. That should cover the majority of cases? I'm concerned that even though you have code in TurboVNC, there will still be a lot of changes (and bugs) as TurboVNC is based on a very different RealVNC code base. > I haven't looked at the RealVNC 4 code recently, but wouldn't that code > be in TigerVNC as well, if it existed? Indeed it would. > >> This is not only > >> disruptive but possibly even violates the fundamental nature of the RFB > >> protocol, > > > > What makes you say that? The protocol doesn't mention anything about > > update rates, only that each update should represent a full screen > > change. So having one client updating at 30 Hz and one at 10 Hz should > > not be an issue. It's just that the second client will see the > > aggregate of three changes (from the first's point of view). > > Isn't the fundamental nature of the RFB protocol client-driven? That > is, it's required that the server not send an update until the client > requests one? Maybe I'm misunderstanding. We seem to be talking about different things. :) I was referring to the deferred updates mechanisms and how that relates to multiple clients, not the CU extension. I agree that CU is a massive conceptual change in RFB. > We can't ever be 100% > server-driven, because the client still has to send FBUR's whenever a > portion of its window is obscured, etc. However, in order to get decent > WAN performance, we are going to have to become mostly server-driven, at > least under certain circumstances. I think server driven should be the norm. The VNC design was just a quick and easy way to solve the flow control issues and is not a good way to move forward. (IMO) 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
------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
