Now the filesystem is generated on-the-fly instead of manually adding and
removing inodes as processes spawn and die.
The code is convoluted and bloated as I wrote it while sleepless. However,
it's still vastly better than the old ProcFS, so I'm committing it.
I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
You're never gonna be right 100% of the time when guessing how much buffer
space you need. This avoids having to make that type of decision in a bunch
of cases. :^)
Work now happens in terms of two messages:
- WM_ClientWantsToPaint
- WM_ClientFinishedPaint
This feels fairly obvious compared to the old Paint/Invalidate.
Instead of clients painting whenever they feel like it, we now ask that they
paint in response to a paint message.
After finishing painting, clients notify the WindowServer about the rect(s)
they painted into and then flush eventually happens, etc.
This stuff leaves us with a lot of badly named things. Need to fix that.
To start painting, call:
gui$get_window_backing_store()
Then finish up with:
gui$release_window_backing_store()
Process will retain the underlying GraphicsBitmap behind the scenes.
This fixes racing between the WindowServer and GUI clients.
This patch also adds a WSWindowLocker that is exactly what it sounds like.
Previously we'd blit every pixel in every window that intersected any dirty
rect to the back buffer. With this patch, we limit ourselves to blitting the
pixels inside the actual dirty rects.
There's still a lot of optimizations to make in this code.
Only booleans are supported at first. More types can be added easily.
Use this to add /proc/sys/wm_flash_flush which when enabled flashes pending
screen flush rects in yellow before they happen.
Technically we could just grab directly at the CharacterDevices like we've
been doing but I'd like to stay away from in-kernel behavior like that.
This should eventually become a userspace process.
Windows that don't intersect any of the dirty rects don't need to be copied
into the back buffer since they won't be affected by the subsequent flushes.
It's a bit confusing that the "current" process is not actually running
while we're inside the scheduler. Perhaps the scheduler should redirect
"current" to its own dummy Process. I'm not sure.
Regardless, this patch improves responsiveness by allowing the scheduler
to unblock a process right after it calls select() in case it already has
a pending wakeup request.
The system can finally idle without burning CPU. :^)
There are some issues with scheduling making the mouse cursor sloppy
and unresponsive that need to be dealt with.
