Fabio Alemagna <[EMAIL PROTECTED]> wrote: > 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?
Exactly because of that, I advocate to avoid making a special (partially) kernelside kludge to a specific target to emulate the current behaviour of another. > The question to answer is: is it possible to automate it? If the answer is > "yes", then it should. Another question to answer is: Will it be possible to automate it on any future target? IMHO the answer is "I'm not sure - very possibly no." > Doesn't matter how difficult it can be: we're talking about design > decisions, and decisions like these should be as farsighted as possible. Ack. And that means that we must be able to handle a possible future target can cannot in any way handle the switchaway transparently. Think about something like a PDA. They have buttons to bring specific Apps to the front. That is pretty similar to a switchaway. Now such a PDA has no MMU usually ... so how do we transparently remap the VidRAM to some normal RAM there? Difficult - right? Now if the app gets an event that it is about to be switched away, it can react, or, if it doesn't, it has to cope with it being stopped and possibly its current framebuffer being destroyed. That is IMHO sowthing that can be implemented on any future braindamage target we might want to address. > Which is what I'm saying: let do it to the kgi target, not to the > application. Why? IMHO the application wants to know, if it is visible. If it ain't, many apps will want to do something different than usually. Many will just want to sleep, some will want to run on, not bothering to update their video output (maybe still providing audio output), still others may want to run on, still providing video output to some backbuffer, ... > > 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. Are they? How many graphics apps do you have that should continue burning CPU when their output cannot be viewed? For quite many (games, multimedia stuff, GUIs without other IO, ...) sleeping is pretty reasonable. > 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 Why can't it tell the library that it wants to sleep for 10 seconds, do something, then sleep again? Easy question: because it is not on the option list. Should we add it? No, right? What then should we do? Just tell the app, that it is not visible, and then let the app sleep, run on, create a backbuffer for its use, ... > In the case (2) the application would get both a "hide" and "expose" > events, and it will then decide what to do by itself, That is what I am advocating. And as the app can decide, it can just decide to sleep for the "got visible" event. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
