Hi again Pierre, Den 2009-05-28 13:54 skrev Pierre Ossman: > On Tue, 19 May 2009 15:45:54 +0200 > Peter Rosin <p...@lysator.liu.se> wrote: > >> Den 2009-05-15 12:20 skrev Pierre Ossman: >>> Although I didn't incorporate you changes in this extension, I have >>> been thinking about them and I think they should be added, but as >>> separate extensions. As such, your comments have been very valuable to >>> me. >> Only one of my suggestions qualifies as a separate extension. Or? >> > > Two, the pixel format (WMVi replacement) and some way of telling the > client possible configurations for SetDesktopSize.
Oh, ok. Didn't think of the possible configs things as a separate extension so that clears up the discrepancy... >> The server will be the easy part to implement, so consider the >> client impact (keep the client easy, remember): You have said >> nothing about WMVi in the EDS spec, so the client has to assume >> that a WMVi rect can appear at any point. > > The WMVi extension is not in the docs, so I don't think it would be > appropriate to mention interactions with it yet. If it were, I'd add > the same requirement that was originally there for DesktopSize; i.e. > the information must not conflict. Maybe WMVi should be documented first then, so that there is no window of opportunity for "bad" implementations, but it's probably good enough if WMVi is documented soon(ish). *snip* >> If you do specify when and how a WMVi rect may appear in the >> presence of EDS rects, you will get away from many of the above >> difficulties. My suggestion is to require that WMVi rects are >> only sent alone or directly after an EDS rect and that FB >> resizes using the WMVi message are disallowed (i.e. allow >> cases 1 and 5). The important thing is to disallow cases 2, 3 >> and 6, but I think you should disallow case 4 (and maybe even >> case 1) while you have a chance. > > Agreed. :) Good! >> > Are you worried about a few extra roundtrips during connection >> > setup? >> > > > When you put it that way, I guess not. :) But I take it you are sticking to the old init protocol. Oh well. Let's commit the dang thing and worry about WMVi later... Cheers, Peter ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
