Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Terje Mathisen Newsgroups: comp.arch Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer? Date: Fri, 20 Sep 2024 09:55:53 +0200 Organization: A noiseless patient Spider Lines: 54 Message-ID: References: <2935676af968e40e7cad204d40cafdcf@www.novabbs.org> <7wCGO.45461$xO0f.1783@fx48.iad> <20240918190414.00005806@yahoo.com> <8e1aed9ce25c70cc555731140ae14eb1@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Date: Fri, 20 Sep 2024 09:55:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5f413b970078924406529bce4531efbd"; logging-data="1069316"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++wvOC2jR42wNp3N4UM5aBf/PS5fDXY7r1eDFWdCC6Tg==" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.19 Cancel-Lock: sha1:/6fl1VG8RDLNTCdN7UQM00yDyTw= In-Reply-To: Bytes: 3828 Lawrence D'Oliveiro wrote: > On Thu, 19 Sep 2024 12:54:23 +0200, Terje Mathisen wrote: >=20 >> The way I implemented it was by updating the "official" back frame >> buffer, and compare the update with the visible front buffer. If at an= y >> 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 fron= t >> and went on from there. >=20 > Is this where the need for =E2=80=9Ctriple buffering=E2=80=9D comes fro= m -- the fact that > you need to copy the entire contents of one buffer to another? >=20 > The way I understood to do flicker-free drawing was with just two buffe= rs > -- =E2=80=9Cdouble buffering=E2=80=9D. And rather than swap the buffer = contents, you just > swapped the pointers to them. >=20 If you cannot swap the buffers with pointer updates, then you need to=20 copy, and if that copy takes a long time, then you might need a third=20 buffer which you actually updating all the time. This would be one HW frame buffer, with a slow write port (ancient IBM=20 CGA needed a bunch of frame times in order to update all of it=20 flicker-free, since you could only write during beam retrace intervals:=20 A few char cells duing each horizontal retrace, several lines during=20 vertical retrace. In the back end you could flip between two buffers in RAM, but I never=20 found a need to do so. I just measured that it was much faster to write=20 a full screen from RAM to frame buffer than it was to do even a partial=20 copy from one part of the frame buffer to another, i.e for doing=20 scrolling within a window. When lots of stuff was happing in my terminal emulator, I would limit=20 screen refreshes so that I didn't have to update the frame buffer more=20 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=20 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 --=20 - "almost all programming can be viewed as an exercise in caching"