On Fri, 24 Apr 2009 09:41:35 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> Den 2009-04-23 10:45 skrev Pierre Ossman: > > As I see it, there are three options here: > > > > 1. Keep the text as it is, making non-incr. a bit odd in that > > it will never give you any data directly. > > 2. Only send the EDS separately on a framebuffer size change. > > 3. Go back to the drawing board and solve the issue of > > bootstrapping the clients view of the screen layout some > > other way. > > > > I'm leaning towards 1, even though it isn't very nice from a conceptual > > point of view. Clients have to deal with that scenario anyway, so we're > > really just changing it from a rare case to the common case. > > > > Comments? > > I get the feeling that everything gets a bit convoluted since you > wish to use non-incr updates as the trigger for sending an EDS > pseudo-rect. I can only see one reason for this: the client needs > to reliably find out if the server supports EDS to know if it's ok > to send SetDesktopSize messages. Correct. There is also the matter of the client getting an initial copy of the screen layout, which isn't included in any init message. > It might be simpler if only the > absolute first non-incr update where special regarding EDS. You > could e.g. require that an EDS-capable server respond to the first > non-incr update with an update that has the EDS pseudo-rect before > any non-pseudo-rects. You would then only need to send an EDS > pseudo-rect when there has been a change (or a denied request from > the client). I'm not sure it's simpler. The mental model of it now gets an extra condition (first non-incr., as opposed to every non-incr.), and I'm not sure the code gets simpler. The server needs to keep track of which non-incr. update is the first and the the client needs to deal with the scenario of non-incr. updates not containing any data anyway (i.e. the client won't be simpler to implement because of this change). I feel a bit like every option results in ugly complexity somewhere. :/ The best option would be if we could extend the init sequence, but I'm not sure that's feasible. 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
------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
