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. > When you say "separate extensions" I assume you are referring to > my WMVi/pixfmt suggestion. Since the only way to change the > server preference of the pixfmt is the WMVi encoding (either that > or reconnecting, bleah), let us see what it will lead to when you > are using both WMVi and EDS. > > 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. > 2) WMVi rect appears in an update without any EDS rect, the FB size > doesn't match the previous full FB size. > > Hmm, what to do. Stupid server. Drop all screens and show the > FB according to the WMVi rect I guess... > See above. > (case 3 - 6) We could mandate that a WMVi must never change the FB size if the client also supports EDS. Kind of how we forbid sending a DS if the client support EDS. > I see two problems for the client. It has to deal with the full > update as a single entity in order to do the combinations from > cases 3, 4 and 5. It is not possible to deal with updates on a > rect by rect basis. The FB pixfmt and the FB size are also > tightly coupled. Sure, on the typical windowed desktop you will > typically have 16 or 32 bits and not bother with anything else. > But if you have a client that can render directly into /dev/fb > (or equivalent), the available FB sizes are strongly dependent > on the desired pixfmt. For such a client it will be double work > to first find a good graphics mode using one pixfmt only to redo > it right away with a different pixfmt. The client will gain from > combining the EDS rect and the WMVi rect and it would be so much > easier if the two were combined into one rect from the server. I belive the problem is that WMVi is fundamentally broken. RFB is all about putting complexity at the server and letting the client use whatever formats it wants. As such, WMVi will always be a pain to handle for clients, What should be done is to have an extension where the server informs the client of the server pixfmt, not shoves it down the client's throat. A client can then decide on its own if it wants/can follow this change. > 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. :) > > > > We could avoid the extra roundtrip though, so there is some gain > > outside of the complexity. > > Are you worried about a few extra roundtrips during connection > setup? > When you put it that way, I guess not. :) 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
------------------------------------------------------------------------------ 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
