> 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.
And it can continue running in background. The signal is just there to notify the application that it is aware of its state and that the framebuffer nor the accel commands are NOT accessable. _How_ the application deals with that situation (i.e. drawing into a backbuffer, storing drawing commands in a queue or do some calculations, etc.) is _completely_ up to itself. > 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! That's stuff that can be done in the GGI target, which means this is transparently to the GGI application. :) > > Right, I had in mind kgi as the only console-based target, subsitute > "kgi-specific" with "console-specific". Wow! We make progress! A point of an agreement! :-)) > > > 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, Well, that's already available. The difference to X and Fresco is, that GGI apps have multiple 'central management systems' called GGI targets. :-) > and if galloc is such a thing, then it should be used. libgalloc is there to manage limited graphic resources GGI applications can request at runtime. > > 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. ok. Second point of agreement. :-)) > > > ... 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 sleep when they're switched away uhmm... Do you know nixterm? It is terminal implemenation on top of libggi. What do you guess, what it does, when it runs in background? It is waiting until you press a key! What does waiting for keypress mean? That means, that it sleeps!! :-)) To wake it up, you must send it a key. How do you send it a key, when it runs in background? ... Do you really think, it makes _NEVER_ sense to put apps to sleep? If you do then please explain me, how a multitasking scheduler works... :) (I know, this is a little offtopic now, but... :-)) > 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. What do you want to exactly avoid? The signal handler, which can be done within the GGI targets or the code, which lets the GGI app react on the event expose? If you wanna do the last case in the GGI target, too, how would you do that? nixterm definitely behaves different than ggidoom, when being in background. :-) > > 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. Third point of agreement! :-)) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
