On Tue, 21 Jan 2003, Christoph Egger wrote: > > Yes, and often the app might want to _continue_ working even if it's > > switched away. > > That's the case, _if_ the application catches the signal.
And that's wrong, imho, because usually apps will want to run in bg, and thus making that the default behaviour will force all apps to handle that case anyway. If there's a way to make the app run in bg without writing one line of code more in it, then it should be implemented. > > Halting the app won't solve the problem anyway: how do you handle halting > > when a VT switch is requested right in the middle of a piece of code which > > is writing to gfx card registers? > > That's an issue, that can be solved within the GGI target: Catch the signal, > and wait until the accel is idle or in any other interruptable state (Note, > high-end > graphic hardware supports context switching in hardware and thus don't > need to be really idle). But you'll need to save the gfx card state somewhere, and restore it later on, hence you might just as well let the application continue running on a framebuffer, or just mmap /dev/null and use it as framebuffer in case the app didn't require a backingstore, or there's not enough memory to make it available to the app, in which case the app would get an "expose" event when switched back again. But let it run! > > What's difficult to get? The user should be able to make the app run on > > whatever target is available, even > > yet-to-write-ones-with-very-special-features, so having to write specific > > code for specific situations which arise only with specific targets > > defeats the whole point of ggi. > > If you are missing a graphic resource management system, then please check > out > http://www.ggi-project.org/xmldoc/bk01pt03ch05.html > and follow the 'next' links. :) Sorry, but I don't understand how that answers to my point? > > > > look there: "vtswitch_request". So, does any ggi app have to implement > > > > that? > > > > > > If it wants other than the default behaviour of "go to sleep if switched > > > away, get a redraw message on switchback": IMHO yes. > > > > the "switch away" event is kgi-specific, > > No. All console based targets as svgalib (Linux), vgl (FreeBSD), aalib, vcsa > (Linux) > and fbdev (Linux) have this "switch away". Right, I had in mind kgi as the only console-based target, subsitute "kgi-specific" with "console-specific". > > on windowed systems when you switch an app away, the app > > is not put to sleep! > > ... because there's an central management system being able to > obtain the drawing operations. ... which should be implemented in ggi as well, and if galloc is such a thing, then it should be used. > > > Don't tell _me_ about the point of GGI. > > > > Uhm? Sorry, but I know the point of ggi very well too. > > Fabio: Andreas is the GGI founder, in case you don't know... :-)) I know that, nevertheless I follow ggi since it was born (you can still find one email of mine related to kgi in the archives), and I know it wery well. I think I have the right to say that I know what's the ggi purpose. > > Maybe I haven't been clear enough: what I don't like is the fact that the > > app gets put to sleep. > [...] > > ... but don't tell me that the right solution in case it doesn't > > understand that is to put it to sleep! > > This behaviour is not a mandatory. It is the default option. And it shouldn't be. That's all I'm advocating: apps usually _don't want_ to be put to slee when they're switched away, which means that every app will have to implement somecode to avoid that: if it's possible to make it automated, then it should be. > > backbuffer first it couldn't take advantage of such functions. > > You can't use accelerated drawing functions, when the app is switched away, I know that very well, however there's no way to use acceleration only when the app is not switched away, because even when the window's app is only partially covered backing store does the job of restoring it to the right state when that part is uncovered again: using an internal buffer would make it impossible to use acceleration at all. > But do you really believe, that X still uses accelerated > drawing functions? In particular, when there's no more onboard gfx RAM available? No, of course not, and it's not what I said. > > I don't _demand_ anything! We were just discussing design decisions, > > weren't we? GGI and KGI is yours, far from me the idea of imposing design > > decisions, I just thought I'd spend my 2 cents and say something about the > > topic too. > > well... then thanks for the flame war. :-) I didn't mean to make it become a flamewar, though. Fabio Alemagna
