> Also... I would have thought/hoped that a simplified/stable solution would
> eliminate "serverGeometry" completely.
>
> /**
> * Geometry retrieved from the
> * last ConfigureNotify event received
> */
> Geometry & geometry () const;
>
> /**
> * Geometry last sent to the server
> */
> Geometry & serverGeometry () const;
>
> I understand why we have, and why we might want, serverGeometry. However it is
> an optimization which only makes sense to attempt if the code is stable and
> bug-free to begin with.
>
> While serious bugs remain, I think the first goal should be to simplify the
> logic down to just using "geometry" and remove or stub "serverGeometry".

There are some usescases for when we need to know what the last /received/ geometry from the server is. That's why the whole geometry/serverGeometry thing exists.

> Also... I would have thought/hoped that a simplified/stable solution would

> eliminate "serverGeometry" completely.

>

> /**

> * Geometry retrieved from the

> * last ConfigureNotify event received

> */

> Geometry & geometry () const;

>

> /**

> * Geometry last sent to the server

> */

> Geometry & serverGeometry () const;

>

> I understand why we have, and why we might want, serverGeometry. However it is

> an optimization which only makes sense to attempt if the code is stable and

> bug-free to begin with.

>

> While serious bugs remain, I think the first goal should be to simplify the

> logic down to just using "geometry" and remove or stub "serverGeometry".

There are some usescases for when we need to know what the last /received/ geometry from the server is. That's why the whole geometry/serverGeometry thing exists.