On Wed, 22 Jan 2003, Fabio Alemagna wrote: > On Wed, 22 Jan 2003, Jos Hulzink wrote: > > Yeah, but if you think well about this, you would see that it doesn't work > > in the general case. > > Sorry, you're just wrong there: it has worked in the general case for > ages, since AmigaOS was born.
Yeah yeah. Amiga OS, the greatest OS of them all. AmigaOS was not a general case, it was an OS for a very specific hardware platform, with very strict rules about hardware. AmigaOS had no backbuffer for 64 graphical consoles. The Amigas had one big advantage: They had hell a lot of memory for that era, and a damn good graphics processor. > > And that is what I / we try to tell you the entire > > time. I assume your OS forgets the ratio between video memory and main > > memory or lacks consoles. In the general case an application must be able > > to deal with the situation it can't draw on, for there will always be a > > user with a configuration where background buffers just don't work. > > Please, just make some examples. Easy, all cases where the user doesn't have a lot of memory: Say I got 64 MB ram, and we allow the kernel and some software to exist in main memory, so we keep 32 MB left. Now I got a good old ViRGE, with 4 MB memory, running 1024x768 @ 32 bpp. Nothing special, right ? With 8 backbuffers I eat 32 MB, or half my main memory. KGI allows up to 64 graphical consoles,plus 64 text consoles. > > Which means that it better deal with this situation gracefully, or else it > > will definitely be stopped. > > There is only one case in which the app should be stopped, and I'll > explain it in another email, in all other cases the default should be to > let the application run, you chose whether with backingstoore or not. That's what I say: It is allowed to run on, while it behaves. And we let nothing but the application itself decide whether it should be stopped or not. > > Questions here: why the hell should an application be able to draw on > > ? It is in the background, the user doesn't see anything, and the ability > > to redraw is needed for other targets anyway. True, sometimes it will cost > > a few seconds to redraw very complex scenes, but that is IMHO the price > > the user pays for console switching on slow machines. The user doesn't > > have to switch, it is a feature. > > What?! The user doesn't have to switch? Are you next time going to say > that the OS doesn't have to multitask, it's just a feature, amnd if it > wants to multitasks then it has to pay the price of slow multitasking? Indeed. If a user wants to run 30 apps at the same time, that's his choice. He shouldn't blame ME for the fact his computer is loosing speed. Oh, and for smooth multitasking you need to switch tasks a few hundred times a second, so milliseconds (and thus optimization) are crucial there. If multitasking costed megabytes per task, it wouldn't be there in your Windows / *BSD / Linux. A normal user doesn't switch consoles every second, it does cost Megabytes to use backbuffers. Besides, you might actually loose a lot of speed when using your "feature": Your kernel has to start swapping a lot earlier. What annoys me most is that you don't answer my question, like you never really have an answer to the arguments against backbuffering in KGI. Or is this your answer: Backbuffering is a MUST for the user must be able to switch graphical consoles 20 times a second. > Bah... Yeah, Bah. A freak that doesn't think beyond AmigaOS and thinks every OS should use backbuffers for AmigaOS did it. So far I have not ever heard a good argumented reason from you why implementing backbuffers is worth the loss of memory, the loss of cpu power, the trouble implementing it. "It is nice" doesn't count for me. But, I'm done with you. Arguments against backbuffering in KGI seem not to reach your mind. Jos
