Hi Denis, > Quoting Stephen GALLIMORE: > > Hi all, > > > > I have been working on a DirectFB port to the SH4 architecture and to CE > > devices > > produced by STMicroelectronics. > > Nice, which devices? Is there public information available? We produce our own complete distribution, which can all be found at http://stlinux.com . We released a new test version of version 2.0 of the distribution last week, but the documentation on the site hasn't caught up yet. Currently a pre 0.9.22 CVS snapshot of DirectFB is shipped with this, I am upgrading this to 0.9.22 this week.
> > > I have noticed that applications (such as > > the > > examples) that draw to the primary surface are not suspended when the VT is > > switched and continue to draw over the framebuffer, along with whatever is > > supposed > > to be on the new VT. > > Yes, that's happening with "fullscreen" applications :( OK, at least I'm not going mad :) > > 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. Am I missing something here, I can't see any other way for two non-multiapp DirectFB applications or a DirectFB application and some random other application on another VT to co-exist. You can't even share the same off-screen surface heap between DirectFB applications on different VTs because display mode might be set at different resolutions and bitdepths, hence the video memory usage is very different between the two. 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. Best Regards, -stephen _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
