Do scrolling commands and/or code that calls posn-at-point do anything
else common with redisplay other than fontification functions?
"Common" is too general a word to give an intelligent and helpful
answer to your question. I have no other way except explaining a lot
of how relevant parts of the display engine work (below), or else we
will be forever trapped in misunderstandings. (I do suggest to read
the commentary and the code in xdisp.c, to facilitate better
communications. It takes time and non-trivial effort to write these
descriptions.)
If *that* work (together with fontification) is usually what takes the
most time during redisplay
This remains to be shown. Someone™ should profile redisplay in
relevant use cases and present the profiles, then we could decide
whether this is or isn't the case. Personally, I think it's roughly
40%-60% or 30%-70%, with the actual redisplay being the larger part.
But humans are notoriously bad in guessing this stuff, so I won't be
surprised if mine turns out to be wrong.
there could be some simple cache added on to of it, which would make
skipping redisplay unnecessary in cases when the command would
pre-fill such cache.
I have my doubts that it will turn out to be simple. Besides my
humble experience of hacking the display code, I have a much more
significant evidence: that such a cache was not implemented when the
current display engine was developed for Emacs 21. Gerd Moellmann is
an extremely capable and talented programmer, and most of the work he
did on the display engine during Emacs 21 development was precisely to
make it fast enough. All the redisplay optimizations we have now were
designed and implemented for that purpose, because without them
redisplay was unbearably slow on the machines we had at that time. At
some point Gerd wrote that he implemented these optimizations one by
one, until he got satisfactory redisplay speed. If there was a simple
way of caching more data to speed this up, I have no doubt we'd have
that already.