On Wed, 22 Jan 2003, Fabio Alemagna wrote: > Not at all! AROS does it, AmigaOS does it, exactly that way! Screens have > buttons on the top right that let them be put to back/front, and > applications NEVER notice it: they continue to run seamlessy and when > their screen is put to front again its content is just like it should be. > > Now, that demonstrates that it's possible to do it, and that's the reason > for which I got so involved in this discussion: I know it can be done - > the OS I code can do it - so I see no reasons as for why ggi/kgi shouldn't > do it.
Yeah, but if you think well about this, you would see that it doesn't work in the general case. 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. Which means that it better deal with this situation gracefully, or else it will definitely be stopped. Now, for it deals with this situation gracefully, there is no need to make KGI a memory hog. And yes, most of the dealing must be done by ggi (the kgi target), but the application must be able to choose the behaviour. 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. Jos
