This one gets rid of a ton of awful, crufty code that was pre-std.
It also removes the following features:
- raw scancode reporting: nobody uses them, and they've never been tested.
They can be added in later if someone wants to e.g. build a MAME emulator.
- multi-listener: there is no good reason to do this on a secure system.
multi-listener is basically a keyboard logger. It's better if we just
control it to a single keyboard listener.
This is a "no good choice" situation but there is a problem with
progress bars.
You want progress bars to update quickly, and you don't want
to have to context switch out for the entire graphics stack to
come back to you to approve the drawing of your progress bar update.
On the other hand, you don't want to short-circuit all the checks
on drawing stuff to the screen for the sake of progress bars --
right now, there are a number of checks in place to make sure you
can't draw stuff on parts of the screen you shouldn't, to avoid
fake messages and dialog boxes.
I had managed to work out a way to get a dialog box to redraw without
violating the security rules -- each redraw is checked by the defacing
routine -- however, due to the way I was computing the height of
the modal I was causing the dialog box to be resized to its largest
size and then shrunk again to fit the text every iteration. This
in essence also caused the defacement routine to run repeatedly,
which caused the GAM to also issue repeated redraw requests to
the main loop.
These redraw requests can't be serviced until the task being tracked
by the progress bar is completed. As the progress bar gets redrawn
almost a hundred times as part of the task, roughly a hundred messages
arrive in the server's queue before it can handle a single one.
This results in a deadlock situation on completion of the progress
bar, because we want to fire off a message to ourselves to go to
the next state in the Ux routine.
There are a few possible solutions to this:
1. Multi thread the heck out of the routine doing the progress bar,
so the dialog box and the slider are each in their own threads
with their own responders and then the thing doing the computation
is doing some Mutex-guarded-Arc thing.
2. Do some very unsafe bodge to allow sliders to do direct draws
that are unchecked
3. Add a check so that if the size of the dialog box doesn't change,
defacement isn't recomputed and thus redraw messages aren't sent back.
(1) doesn't work for a number of reasons -- in a general case, it's
probably OK, but it does cause a lot more memory usage (and we are
lean on memory); but more importantly, for this use case, our routine
is interacting with CSRs and those don't implement Send so you can't
pass them into a thread via a closure. You could maybe put the dialog
boxes themselves into an Arc Mutex thing but because this routine
was heavily coded to re-use the heavyweight Ux resources this becomes
a bit cumersome to code.
(2) is terrible
(3) ended up working and what is in this commit. I think it's OK
because a progress bar generally doesn't require changing the
size of a window to update its state; therefore the redraw is
deface-safe (since you aren't changing the bounds of what you were
already approved to draw in). Of course, if you have some sort
of a progress bar implementation that changes the size of the messages
reported up top so that the dialog box has to change size over and
over again, you still end up in the deadlock situation!
also add some bread crumbs on the more user-facing APIs to
help beginners out. Need to do a good spring cleaning of the
rustdoc tree, though. looks pretty terrible as it is.
this ensures that "all back" dialog boxes that are fake
are also defaced (as opposed to just drawing black, which
would not deface a "fake" dialog box).
classic code rot resulting from adding stuff that was never designed
to be in part of what was originally just a test loop to show
uptime.
cleaned it up, idle CPU load drops from 8% -> 2-3%.
