On Mon, 16 Mar 2009 16:54:20 +0100 Peter Rosin <p...@lysator.liu.se> wrote:
> Den 2009-03-16 15:00 skrev Pierre Ossman: > > > > Annoying. Do they also rely on putting the conversion requirements on > > the client? > > Yes. If a client claims support for WMVi, it has to support all pixfmts > (or disconnect on reception of something unlikeable). > But what if the client doesn't claim to support it? Seems like they have to implement format conversion in the server anyway. > > > > Indeed, but describing such limitations can be very difficult. How do > > you describe the non-overlapping requirement for example? > > > > I don't see the method of requesting one thing and potentially getting > > something completely different back as a decent solution. In most cases > > it will just be plain confusing. > > > > Could you describe how the client could suitably react to such a > > response? > > I wasn't proposing that the exact restrictions were described. I didn't > propose that the server response would actually be used, it would just > be a hint so that the client would have at least some request that worked. > But the client would probably need to adjust the server reply further. > > An example (using monospace font): > > Server has two screens 1024x768, side-by-side, fb-size 2048x768. > --------------------- > | | | > | | | > | | | > --------------------- > Client the asks for the initial two screens, plus a third screen 800x600 > which is halfway overlapping the rightmost screen, fb-size 2448x768. > ------------------------- > | | | | | > | | | | | > | | ----|---- > --------------------- > Server says "no" (since it can't handle overlapping screens) and informs > the client that it could change its request to not have any overlaps, > i.e. make the third screen only 400x600, fb-size still 2448x768. > ------------------------- > | | | | > | | | | > | | |---- > --------------------- > The client can then do what it wants with that info. If it takes it, it > could render on only half its third screen. > Or the server might decide to move the overlapping screen to the right instead. And since it has no idea what the client's restrictions are, the client might need to readjust what the server wants. And then things quickly spiral out of control. :) A mechanism that allows the client to handle server side limitations would be fantastic. But the only solutions I see either cannot describe all the possible limitations, or start to cross over into the whole "implementation defined" neck of the woods. And "implementation defined" is the greater evil IMO, so I've opted for an incomplete, but common set of restrictions. We might want more/other fields than what I've proposed, but the whole "throw stuff at the server and see what comes back" approach does not give me a good feeling. > Since it is nearly impossible to envision all possible server side > limitations, we shouldn't even try. Instead, let the server come up with > one possible workaround for the client, but never force that suggestion > on the client. The client can always request something completely > different, should it dislike the server suggestion. People tend to follow popular implementations, not the specification. So I don't think we should add anything on the premise "might be useful, perhaps, but everyone else can just ignore it" as there is a high risk of implementations popping up that rely on this optional behaviour. I believe the only sane way is to have a set of restrictions where the client can compute beforehand if a request will fail, and a failsafe of the server saying "no" for the restrictions that we were unable to describe. The server might for example be saying no just because it doesn't allow any changes at all. What would it fill into the fields as a suggested alternative at that point? 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
