We were reading one client message per client per event loop iteration.
That was not very snappy. Make the sockets non-blocking and read() until
there are no messages left.
It would be even better to make as few calls to read() as possible to
reduce context switching, but this is already a huge improvement.
This is really cool! :^)
Apps currently refuse to start if the WindowServer isn't listening on the
socket in /wsportal. This makes sense, but I guess it would also be nice
to have some sort of "wait for server on startup" mode.
This has performance issues, and I'll work on those, but this stuff seems
to actually work and I'm very happy with that.
This is a lot nicer than the big switch full of code. This stuff has a bit
of a "please generate me instead" vibe to it, but I need to mess around with
it some more to figure out what the needs are.
This patch also unbreaks global cursor tracking, which was forgotten in the
big messaging refactoring.
In order to move the WindowServer to userspace, I have to eliminate its
dependence on system call facilities. The communication channel with each
client needs to be message-based in both directions.
WSWindowManager::invalidate() had a bug where it would mark the entire screen
rect as dirty, but it wouldn't scheduled a deferred recompose.
This would cause any subsequent calls to invalidate(Rect) to be coalesced
with the pending compose, but the pending compose never happened.
Since we know who's holding the lock, and we're gonna have to yield anyway,
we can just ask the scheduler to donate any remaining ticks to that process.
Work now happens in terms of two messages:
- WM_ClientWantsToPaint
- WM_ClientFinishedPaint
This feels fairly obvious compared to the old Paint/Invalidate.
