Making Composite better for interactive apps

[Giuseppe Bilotta]

On Mon, Feb 5, 2018 at 4:27 AM, Keith Packard <keithp at keithp.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta at gmail.com> writes:
>
>> I'm not sure if this could be implemented without making the server
>> more susceptible to DOS attacks, though (basically the same issue I
>> see in the blocking AutoList geometry change notification).
>
> In that case, the Window Manager can already perform DoS attacks by
> simply never mapping the window.  Similarly, the Compositing Manager can
> DoS the system by never painting anything. Given that one generally
> starts a Window Manager/Compositing Manager at the start of the session,
> and that only one of either can be running at a time, there shouldn't be
> any way for such a DoS to occur.

Eh, sometimes I miss the obvious 8-D.

So the only difference between the two approaches is that in the
current async way the server can cover the latency that would come
from waiting for the WM to complete the mapping (or in general other
such requests) by processing other events, but this comes at the cost
of the complexity inevitably deriving from the asynchronicity itself,
both in terms of protocol and in things like trying to guarantee
consistency between disparate events affecting the same windows (such
as the geometry changes' interaction with the presentation that we
discussed so far).

I must say I'm a bit conflicted about this. I actually like the mostly
asynchronous nature of the X11 protocol (but that might just be a
perversion of mine developed over years of HPC). In fact, the thing I
like the least about it is that the C language doesn't have something
that maps naturally to it (while the C++11 std::future actually do). I
do agree however that having some better ways to enforce sequencing in
some circumstances would be preferrable.

> In any case, we're not likely to change how window management works at
> this point; toolkits have dealt with re-directed configuration for over
> thirty years at this point.

Well, obviously, these would be more along general thoughts about how
things could be different for X12 ;-) Or at least design principles
that may be kept in mind for future extensions.

-- 
Giuseppe "Oblomov" Bilotta