Sujet : Re: Is Intel exceptionally unsuccessful as an architecture designer?
De : terje.mathisen (at) *nospam* tmsw.no (Terje Mathisen)
Groupes : comp.archDate : 20. Sep 2024, 08:55:53
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vcj9q9$10k84$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.19
Lawrence D'Oliveiro wrote:
On Thu, 19 Sep 2024 12:54:23 +0200, Terje Mathisen wrote:
The way I implemented it was by updating the "official" back frame
buffer, and compare the update with the visible front buffer. If at any
time a write to the back buffer did not result in something that was
already in the front buffer, I just copied the back buffer to the front
and went on from there.
Is this where the need for “triple buffering” comes from -- the fact that
you need to copy the entire contents of one buffer to another?
The way I understood to do flicker-free drawing was with just two buffers
-- “double buffering”. And rather than swap the buffer contents, you just
swapped the pointers to them.
If you cannot swap the buffers with pointer updates, then you need to copy, and if that copy takes a long time, then you might need a third buffer which you actually updating all the time.
This would be one HW frame buffer, with a slow write port (ancient IBM CGA needed a bunch of frame times in order to update all of it flicker-free, since you could only write during beam retrace intervals: A few char cells duing each horizontal retrace, several lines during vertical retrace.
In the back end you could flip between two buffers in RAM, but I never found a need to do so. I just measured that it was much faster to write a full screen from RAM to frame buffer than it was to do even a partial copy from one part of the frame buffer to another, i.e for doing scrolling within a window.
When lots of stuff was happing in my terminal emulator, I would limit screen refreshes so that I didn't have to update the frame buffer more than maybe 20 times/second. For smaller updates, they would be instantly visible (during the next horizontal retrace).
BTW, my back buffer was a list of lines, so that I could scroll by just uninking the top line and adding a blank at the bottom, I tried to limit the number of bulk RAM accesses as much as possible.
Terje
-- - <Terje.Mathisen at tmsw.no>"almost all programming can be viewed as an exercise in caching"