Clicking the button generates a WindowCloseRequest event which the client app
then has to deal with. The default behavior for GWindow is to close() itself.
I also added a flag, GWindow::should_exit_event_loop_on_close() which does
what it sounds like it does.
This patch exposed some bugs in GWindow and GWidget teardown.
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.
