Nope, the reader re-renders the full page no matter what (you can check by running
fbink -Vmph -y -1 " ", that'll draw a black band at the bottom of the screen).
(Note that *drawing* and *refreshing* are two different concepts. Although, in this case, it's somewhat irrelevant, since the reader does *both* anyway. Whether the screen flashes or not is simply another *type* of refresh
.
strace -fitv -e trace=ioctl -X verbose -p $(pidof nickel) if you want to take a look at what's happening on the refresh front.).
1/ We've tried that before, and the results were... inconclusive (IIRC, the least unreliable way was the Event table, which is only updated in batches, and needs to be actively tracked to pinpoint what actually happened, which makes the whole thing tedious and not-actually terribly reliable ;p).
I don't recall where the latest round of discussions occurred, exactly, but there was a small amount of messages on the subject, with at least @davidfor and myself participating, if you want to take a look at that
. (It, err, might even be in this very thread, come to think of it
).
2/ That's essentially what @frostschutz was hinting at by mentioning the nightmode hack (because it interposes the MXCFB refresh ioctl).
While hooking that, and writing to the fb before executing the incoming call as-is might be neat, the extra processing involved might end up significantly delaying the call. Probably better to just pass it through, and simply do another draw+refresh *after* that.
AFAIK (before my time), the plugins system dates back to earlier Qt4 versions of Nickel, so, nope
.