On Tue, 21 Jan 2003, Christoph Egger wrote:
> > 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.
And I advocate that if possible it should be all automated: when
applications run on the X target they don't have to bother with such
things, so why should that bother when they run on console targets? And
what if another tartet comes out which has other special needs?
The question to answer is: is it possible to automate it? If the answer is
"yes", then it should. Doesn't matter how difficult it can be: we're
talking about design decisions, and decisions like these should be as
farsighted as possible.
> > 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. :)
Which is what I'm saying: let do it to the kgi target, not to the
application.
> > > 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?
Did I say that? I rather said that such cases are not the majority of
cases, and as such shouldn't become the default.
> If you do then please explain me, how a multitasking scheduler works... :)
> (I know, this is a little offtopic now, but... :-))
I really don't like this attitute... questioning my knowledges is a bit
over the top, specially because I code an OS, so I should know how a
multitasking scheduler works...
> > 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. :-)
I propose this:
The application can tell the target that, when it loses visibility, it
wants to either
1) Continue running on a backbuffer
2) Continue running without backbuffer
3) Be stopped with a backbuffer
4) Be stopped without a backbuffer
Case (3) and (4) should never be the default, and it's debatable which one
of case (1) and (2) should be the default: it depends on how much code has
already been written and which relies on the _current_ ggi default
behaviour, however if I had to take the decision on the sole basis of
thoretical design principles I'd make the option (2) be the defaul.
In the case (2) the application would get both a "hide" and "expose"
events, and it will then decide what to do by itself, in case (3) the
application wouldnever know it had been switched away, and in case (4) the
application would get an "expose" message when it got switched back.
Fabio Alemagna
