Quoting Stephen GALLIMORE: > > > > Until now applications are not expecting drawing commands to fail. > > > > The window stacking code is aware of suspends and discards any > > updates during suspend, but recomposites the complete stack (screen) > > when the session is resumed. > > > > One possibility would be to move the video only surfaces into system > > memory during suspend. The only case which is not covered is when > > an application just holds the lock on a surface buffer in video memory > > and continues to write to it while the session is suspended. > I assumed that video only surfaces were being backed into system memory > on a suspend in the windowed case; otherwise the contents of the off-screen > surface heap (i.e. pre-rendered images or images loaded from file) will get > corrupted. I had guessed that part of the time it takes to switch between > DirectFB apps in this way (between 1.5-3 seconds on my test platform) was > to do this.
Most surfaces are "auto video" surfaces which are backed in system memory during suspend. > However, while this is interesting, it isn't something that is a big > issue at the moment. We have a user who was interested in quickly > switching between two independent full screen applications and who > wanted to use the multi-app stuff to do this (which we had never > tried before). They are probably correct in wanting to use that solution > for the switching times they want (<1sec, i.e. reasonable response > time to a remote control button press), but I just wondered why not > use VTs instead - it seemed a simple and existing solution to the > problem that didn't require the user to write any new code. Switching between applications within one DirectFB session should be faster, yes. But if both applications have a lot of offscreen images that don't fit into video memory at once you will have a small delay for surface management during switch though. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
