On Mon, 16 Mar 2009 10:44:07 +0100 Peter Rosin <p...@lysator.liu.se> wrote:
> > Hi Pierre! > > There is also the WMVi pseudo-encoding (0x574d5669, or "WMVi" in FourCC) > to consider. A problem with this new proposal is that *both* WMVi and > this multihead scheme are "better than" the DesktopSize pseudo-encoding. > But the multihead scheme doesn't do the stuff that WMVi does (i.e. > handle server side pixel format changes). I fear that appempts to > implement support for both WMVi and this proposal will lead to undesired > complexity. > > So, I'm asking for a way to incorporate server side pixel format changes > in this proposal so that it can superseed both WMVi and DesktopSize. > I don't see a huge gain from including it into these message. We could just as well implement the server pixel format hint as another pseudoencoding. Since it is a strict server-to-client communication, we don't need to think about allocations in the more limited command space. > That said, there is one thing that I don't like about WMVi, and that is > the fact that the server changes the "wire" pixel format without a chance > for the client to say no. I would not mind at all if that was revised, > should a pixel format changes be added to this proposal, so that the > server instead simply informed that its preferred pixel format has > changed. The client would then be in full control of what pixel formats > it needs to support, and my feeling is that this is more in line with > the spirit of the RFB protocol. That would be very against the RFB mentality, yes. But the wiki entry you pointed to suggests that these encodings are just used for "offline" rendering. At that point there is no possibility for the server to adjust to the client's need, so you have to mandate that the client will use the server's native format. > Even if it wouldn't add needless complexity if the server were to send > a WMVi rect for some changes and a ExDesktopSize rect for some other > changes and perhaps two rects for some classes of changes, I still think > there is value in an "advisory" notification that the server has changed > its preferred pixel format, and this seems like a good opportunity to > sneak that into the RFB protocol ;-) I agree that such a hint could be useful. I'm not convinced it needs to be included in these messages. Besides, a server and client should implement support for all variants anyway to give good backwards compatibility. > > And lastly, some comments on details in the proposal: > > There is no way for the server to tell a client how it can change its > SetDesktopSize message so that it gets something that is ok for the > server. If e.g. the server has some resource limit that prevents it from > making framebuffers wider than 2048 pixels (just an example, the example > has no bearing on any particular HW), then the server has no way to > indicate to the client that it must keep below that limit. One way to > solve that would be for the server to fill in the ExtendedDesktopSize > rect with values that may work better when y-position is non-zero, > instead of simply echoing the current state (which the client should > already know). But perhaps that would be too complex. My main point is > that it's very limitied to only have 16 bits (the y-position) to > describe a problem. Perhaps an error string? Strings are not machine parsable, nor translatable (unless you mandate exactly what they should say, at which point you might as well use a code for them). When it comes to this specific problem, the current protocol suggestion should already handle it: "The x-min, y-min, x-max, and y-max indicates server imposed limits of the framebuffer. The client can use this information to indicate to the user when resizing (using SetDesktopSize) is possible." > > The x position of the pseudo-rect indicates the "reason for the change", > and an ExtendedDesktopSize pseudo-rect should also be sent in response > to non-incremental FrameBufferUpdateRequests. I'm missing "non-i FBUR" > as a reason in the enumeration (even if that isn't a /change/ as such). > Ah, sorry. The intent was to have 0 be roughly "server side change" and include the non-i FBUR. That meaning got lost in some revision. How about this replacement text: 0 - The screen layout was changed via non-RFB means on the server. For example the server may have provided means for server-side applications to manipulate the screen layout. This code is also used when the client sends a non-incremental FrameBufferUpdateRequest to learn the server's current state. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
