Den 2009-05-11 13:24 skrev Pierre Ossman: > On Tue, 05 May 2009 11:53:27 +0200 > Peter Rosin wrote: > >> That doesn't solve anything though. I would like my implementation to >> be compatible with both the spec and the wilderness. Tightening the >> spec after the fact does not achieve that goal. >> > > 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." It's too late to tidy things up. >> Aaarghh, the RealVNC interpretation is really insane. You then have to >> wait for the whole update and check if the last rect is a DesktopSize >> rect before you start taking any other action (either that, or you need >> some way to backtrack what you just did and then redo it after changing >> FB size when you discover a DesktopSize rect, good luck with that...). >> > > 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. >>> Unless we want a convoluted specification where the requirements on the >>> server and client do not match up in a symmetrical manner, we need to >>> select on one model and declare the other one a buggy exception. There >>> is the RealVNC model where the client keeps the framebuffer, or the >>> Tight model where the client throws it away. The latter is the simpler >>> and more common one. >> Here you are not making sense. First you say that UltraVNC is the only >> one to send non-incr, so the others you mention should be sending incr. >> But then you say that in the tight model the client throws the FB >> away, but the only way to do that AFAICT is to send a non-incr FBU >> request. So, which way is it? > > 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. > The spec. is (unfortunately) completely silent > as to what happens to the FB data when it changes size. The original > implementation assumed it would be lost, hence sending a incr FUR was > safe as the server would consider the entire screen modified. > > Personally, I think this model makes a lot of sense as it keeps using > incr for the "normal" case. Keeping the FB contents over a change adds > complexity and I don't think there is much gain anyway as the entire > desktop is likely to refresh. Agreed, it makes sence. But the spec has been unclear and we have major competing implementations. >> Anyway, do you really think RealVNC is going to change due to something >> we write in our forked spec? I would very much like to be compatible >> with RealVNC. Same thing with UltraVNC, as much as is possible without >> breaking the spec anyway (writing a client that talks to an Ultra server >> is ok, but writing a server that can handle the Ultra client is worse). >> And I would like the spec to be compatible with existing versions, not >> ones that might, if we are lucky, be produced in the future. > > I'd like to think that my version handles all existing implementations > since it mentions the gotchas. > >> So IMO, declaring stuff that exists today and that is compatible with >> the original spec as "buggy" is out of the question. > > I think that when the original spec is unclear, the original (with > regard to the extension) or most popular implementation should govern > the updated spec, not RealVNC's implementation. I think that RealVNC is quite special, given who is behind it and who has written the spec. > 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. So, if there are grey areas with differering implementations then yes, we can and probably should recommend the sane choice, but we can't outlaw the alternatives. If there are grey areas but only one implementation (like the CPIXEL note I sent the other day), we are free to clear up the confusion. Quite possibly we should mark those places in the document though, so that the reader knows what is our clarifications and what is really the spec. >>> +The old framebuffer data does not need to be preserved when the >>> +framebuffer changes size. The server must therefore not use any >>> +encoding that relies on the previous contents of the framebuffer. >> The way I read this is that the server may not assume that the >> client has retained any fb data. To me, that has the implication >> that the server must send a full update. Since the server has to >> do that, the client might as well *always* issue a non-incr FBU >> request in response to a DesktopSize rect. >> >> A bonus is that it's a very simple recommendation that is hard >> to misinterpret. >> > > I find such specs utterly confusing. The description for the server and > the client should match up, and requiring the client to send a non-incr > FUR when the server will send a full update anyway does not make sense > and only leaves the reader with the impression that they must have > misinterpreted the spec. > > IMO, we should have one sensible primary behaviour, followed by > exceptions to cover existing implementations. 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. >> Also, a note on this paragraph: >> >>> +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 in the following update. Doing so would >>> +make the system go into an infinite loop. >> I think it's wrong to disallow all back-to-back uses of DesktopSize >> rects. What we want to disallow are servers issuing an automatic >> DesktopSize rect in response to each and every non-incr FBU request >> they see > > 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. >> (but that's an ExDesktopSize-ism that doesn't really apply >> to plain old DesktopSize). >> > > 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). >> (and I further think you should disallow sending DesktopSize >> rects to a client that supports both DesktopSize and ExDesktopSize, >> allowing both will just add complications without any gain). > > I figured that servers could get a bit simpler by not having to check > both in combination, and clients need to have the logic to determine if > the FB dimensions change anyway. 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. So, we have to assume that clients sends a non-incr FBU request in response to DesktopSize rects. 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. 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. I stand by my recommendation to disallow servers from sending both DS and ExDS rects. Cheers, Peter ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
