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. :)
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. > > > > Or, what RealVNC's client does, move the old data over to the newly > > allocated framebuffer when it gets the DesktopSize. > > I have not looked at the implementation, but if your description is > accurate, they can't fill the whole FB (in that update) in case it is > growing. > Quite right, which sort of violates the principle that every update is a transition from one valid state to another. The client will get the missing pieces on the next update (even without non-incr as the first updated didn't have a request area that covered the entire, now larger, screen). > > > > 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. :) > > 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. 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. > > 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. > > > > Indeed. Alternative wording welcome. > > Huh? I already suggested an alternate wording in my version > of the patch: > > As some clients send a *FramebufferUpdateRequest* with *incremental* > set to zero, because of the issue above, the server must not send a new > *DesktopSize* pseudo-rectangle as an automatic response to all > *FramebufferUpdateRequests* with *incremental* set to zero. Doing so > would make the system go into an infinite loop. > Oh, sorry. I completely missed that. :/ > > > > 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. > > 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. > 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. :) > 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). > > 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. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
