Den 2009-05-15 11:24 skrev Pierre Ossman: > It seems we agree that implementations should be done in a way that > supports everything, we just need to agree on a wording that conveys > that. :)
Indeed :-) > On Thu, 14 May 2009 15:04:27 +0200 > Peter Rosin <p...@lysator.liu.se> wrote: > >> Den 2009-05-11 13:24 skrev Pierre Ossman: >>> That was not my intention. The message was supposed to be "Don't do >>> this, it's wrong, but be prepared that such implementations exist in >>> the wild". >>> >>> Do you disagree with that message, or just how it's conveyed? >> I guess I disagree. I wish I could agree though, as it would simplify >> things. I think the message should be "There is confusion on how to >> interpret this message as the spec has been unclear for a long time. >> To avoid this confusion, clients should respond with a non-incr FBU >> request and servers should assume that clients need a full update >> following an update with a DesktopSize rect." >> > > Ok. What I'd like to include is some message of how it was originally > meant to work. I find that it makes the system easier to understand, > even if you have to go away from that "perfect" model to be compatible > with reality. That's fine. I just don't like to fool the reader into one view (the "perfect" model) and then have the real stuff last. It might be that it is clearest to start the description with how it was originally meant to work, but in that case it should include some wording that makes it apparant from the start that this mode of thinking is too simplistic for a real implementation. >>> Your assumption here that throwing away the FB means you have to send a >>> non-incr. FUR is wrong. >> Not from the client side of things. If the client throws its FB away, it >> should send a non-incr FBU request. IMHO of course. >> > > I guess it comes down to how you interpret "...if for some reason the > client has lost the contents...". The fact that we interpret it > differently suggest we need to be explicit here. :) Well, the first reason I can think of is if the client window has been obscured but is now brought on top. If the client does not have a copy, then it has to do the non-incr dance. It *could* have kept a copy of the contents of the FB in system memory though. I fail to see how this is fundamentally different from a client that is not keeping a copy in system memory during a graphics mode switch due to a DesktopSize rect. The non-incr FBU request is equally valid in both cases IMHO. >> I think that RealVNC is quite special, given who is behind it >> and who has written the spec. >> > > To some extent, but I don't think they should have carte blanch to do > silly (incompatible) things just because they happen to be sitting on > the official spec. Of course not, but this has been sitting for too long in the spec, without any protests AFAIK. > Does anyone have any numbers on the market share of different VNC > implementations? > >>> That will occasionally mean we'll have to declare some implementations >>> "buggy", but that's unavoidable. What we can do is mention those >>> "buggy" implementations with suggested tweaks to stay compatible. >> We have forked the spec. If we don't stay compatible with the orig >> spec, we will probably lose and will end up the bastard spec that, >> like UltraVNC, is "not VNC-compatible". I thought of "our" spec as >> a place to add extensions without any agenda to change the spec in >> a way that invalidates valid existing interpretations. > > I agree fully and I did not intend to suggest otherwise. I have no > desire for this to be another RFB spec, but rather _the_ RFB spec that > covers every implementation. Good! >> Well, I think it is confusing to have a spec that in detail describes >> how it could work (but doesn't), and then has the description of what >> is really working stuffed away in exception paragraphs. >> >> We should clarify how alternate (valid) implementations behave, then >> go on to describe how to live with it. >> > > I think we're at a point where we can only agree to disagree. > > I'm not religious about this, so if you feel strongly about it then I > can live with your version. I guess I got a bit overboard. I had this feeling that you wanted to describe DS in a way that made EDS look similar. But since you have agreed to not allow DS rects when the client supports EDS, I am more at ease. >>> I'd say it does. The problem is that "non-incremental" is rather >>> undefined when it comes to pseudo-encodings. Am I for example >>> guaranteed to get a new "Cursor" rect on a non-incr FUR? It is quite >>> possible that if I've discarded the FB that I've also dropped the >>> cursor data. >> Since the spec says nothing on the subject the client can not assume >> anything. So, the client should keep a copy of the cursor bits if there >> is a risk that it might need to recreate the cursor (unless we research >> the wild and find that all (major) current implementations do in fact >> send the cursor bits on non-incr FUR, in that case we can tighten the >> spec and allow clients to "officially" use that method to restore a >> discarded cursor). >> > > Unfortunately many do not use that line of reasoning. People tend to > guess as to what was really meant, and (hopefully) might test it with > one or two other implementations. > > We can't do much about the existing problems, but we can keep this in > mind for future additions and try to get this behaviour properly > specified before there are multiple implementations. Indeed. >> I think we both agree(?) that in order to write a client that can >> handle DesktopSize-capable servers in a compatible way, it is sensible >> to send a non-incr FBU request in response to DesktopSize rects. >> > > We both agree that clients need to deal with this, yes. But I think > that RealVNC's version of copying the framebuffer data is acceptable as > well. Yes, agreed. >> So, we have to assume that clients sends a non-incr FBU request in >> response to DesktopSize rects. > > Just to clarify, I'm assuming you mean to say that servers need to be > prepared for clients doing that, not assuming that every client does > it. :) Exactly. >> Now you want to send both a DS rect >> and a ExDS rect to the client since it will simplify the server. >> I claim that the complication in the client is greater compared to >> a couple of simple tests in the server. The major difference here >> is that the server sits on all information from the start, it knows >> for certain if the client supports both DS and ExDS. The client >> can not know in advance if it is going to receive both a DS and an >> ExDS or if it is only going to receive one of them. So, the client >> will have to delay the non-incr FBU request (the compatible >> response to a DS rect) until it is clear that no ExDS rect is >> appearing (or has appeared). Yuck. And we should keep the client >> as simple as possible. > > I see your point and I agree that it's probably best to add that > restriction. I'll update my patch (and TigerVNC). Thanks! >> You want to say that all DS rects come in their own update. But >> that's just not going to happen, so a compatible client cannot >> assume this and will therefore suffer from the complexity of not >> handling all DS rects equally. And the only benefit is that there >> will be a teeny-weeny simplification possible in your server. Not >> a good tradeoff IMHO. > > No, it's not just about simplifying the server (it actually got more > complex). The point is that any data mixed in with the DS will probably > be discarded anyway (or with the RealVNC client, resulting in a > temporarily incomplete framebuffer). So it's just a waste of time and > bandwidth to include that data. I don't think that's what I meant, but that doesn't really matter either. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
