On Tue, 21 Jan 2003, Andreas Beck wrote: > > > The Hardware has quite some state, and not all of it can be retirieved > > > easily. Thus basically IMHO we will have to face the fact, that the > > > application will have to cooperate a little when switching away. > > If Amigas can do it, > > Amigas have a very limited hardware choice
Not really, you can use pretty much any gfx card with them, given the driver is available. There are quite a lot of gfx drivers available. Moreover, AROS which is a reimplementation of AmigaOS can do it too. > > if AROS can do it, then also kgi can do it. Even windows can do it, heck. > > Windows cannot. Look at any semi-crashed application (i.e. one in an endless > loop) there. If it does not redraw a window on its own anymore, it will > not revert to the previos state when you move something over it. What has that to do with the matter we're discussing here? That's just about not responding to redraw events, but that's not the only way windows can work, like it's not the only way X can work. We were discussing about full screen apps, weren't we? > > Yes, and you will have to save that stuff somewhere _anyway_, because how > > else are you going to restore it when the application's VT gets switched > > on again? > > You don't. You tell the app to redraw. That is what X does, that is what > almost everything else does. Try it. X doesn't necessarily behave like that. You can tell it to use a "backing store", and no redrawing events will be sent to the app. > Because switching away form an application doesn't happen nicely scheduled > between the lines of a C program. It happens in an interrupt handler > that originated from the keyboard. The application is very probably > running and possibly interrupted within some drawing loop. Say it just > does a memset() inside the mmaped graphics RAM. Applications should lock the gfx mem when accessing it and unlock when non accessing it anymore. SDL has such primitive, I recall also ggi has one? I'm not sure about this. By using locking and shared memory VT switching could be put to wait until the gfx mem gets unlocked. > > It happens all the times when using X, > > It does not. You can turn on backing store in the X server, but that > is pretty optional and rarely really needed. It makes much sense over > slow lines, where redrawing is very expensive, but generally not locally. But it can happen. > > so why shoudln't it happen when using the console? If the user opens 10 > > apps all using big screens at big depths, then he should be aware that he > > needs a lot of ram. > > What's when we are swapping already? Want to wait for a few Megs to be > swapped free to buffer the output of an application that will not > be relevant on switchback anyway? Look, it could be implemented _exactly_ like in X: applications can request backing store if they want, so let's do it with ggi/kgi too: if apps request backing store, just let them go to background and provide them with a backing store, if they don't request it then just ignore any gfx request when they are not visible, and send them show/hide events. Optionally applications could even _request_ to be put to sleep when they are not visible. So you have 3 options there: backing store, redrawing and sleep. Let the programmer chose. It would be really annoying, for example, if I started my favourite fractal application, then switched console to do some programming, and after one hour I went back to the fractal app just to discover that it didn't do _anything_ because it's been put to sleep. On the other hand I don't want to stare at the fractal while it's slowly being calculated. You see, that's a perfect example of an application that NEEDS backing store and that NEEDS to NOT be put to sleep. Another example would be AROS: AROS can both be run in standalone mode, taking possess of whe whole machine, and in "hosted" mode, where it runs within another OS and the device drivers are just wrappers around the host's device drivers: I migth want to make a KGI gfx target for AROS (currently it uses X), thus needing both backing store and the ability to switch console without putting the _whole os_ to sleep. AROS currently uses backing store even on X. Fabio Alemagna
