On Wed, 22 Apr 2009 17:43:00 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> Den 2009-04-22 16:34 skrev Pierre Ossman:
> > In case someone has already started looking at implementing this,
> > here's another update.
> >
> > Changed:
> >
> > - Require that the ExtendedDesktopSize is sent without any data
> > updates.
>
> I think it would be useful to explicitely state somewhere that a
> client receiving an ExtendedDesktopSize rectangle with the size of
> the framebuffer that it already knows about must not issue a
> FramebufferUpdateRequest with incremental set to zero (unless it
> has some other reason to do so).
>
> I'm sure you have implemented your client to not issue needless
> non-incremental update requests in this case, but it is the simple
> thing to do. Since it leads to disaster to do the simple thing it
> should be noted explicitely that you must not do so, methinks.
>
It never hurts to be explicit, although hopefully every server they
test against has followed the spec. so that they'll directly notice
their mistake. :)
I've been thinking a bit more about this and there is another issue.
Consider the following:
1. Client sends a non-incr. update
2. Server sends an update with only the EDS, since it cannot be
combined with data.
3. Client sends a incr. update
4. Server sends the data for the entire desktop.
This works, but it breaks the mental model of non-incremental updates,
so I'm not entirely pleased with it.
On idea I had was to state that an EDS may be mixed with data if the
framebuffer size hasn't changed. This complicates the EDS handling, but
keeps the non-incr. model correct for the normal case.
Unfortunately the model can break even without EDS, so the non-incr.
behaviour isn't always consistent. Consider this:
1. Client sends incr. update
2. Server sends changed data
3. Server changes the desktop size, queueing up a DesktopSize
event.
4. Client looses the framebuffer, sends a non-incr. update
5. Server sends an update with only the DS, since it should not
be combined with data.
6. Client sends a incr. update
7. Server sends the data for the entire desktop
IOW, the clients must be prepared to deal with a non-incr. update not
giving any actual data anyway, only it is very rare under normal
conditions.
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?
> Nitpick: in several places you have written "a ExtendedDesktopSize",
> it should be "an ExtendedDesktopSize".
>
Ooops. I've been having "rectangle" at the front of the cortex. :)
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
------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
