On Wed, 2009-11-18 at 17:44 +0100, ext Cornelius Hald wrote: > I see many use cases for those policies like an incoming phone call > should work properly even while some app is doing heavy number > crunching. > > However rotation is a different thing. I mean what's the objective? The > rotation animation should be smooth even if something uses a lot of > processing time? Fair enough. But pausing the _foreground_ application > is hardly the solution. How about pausing all _background_ applications?
You are right. This is the bug :) -Kimmo > > The foreground application is the only application interested in the > rotation. Therefore it already specifies explicitly that it can rotate. > If I now write an application it's my duty to give the CPU some time > while rotating. If I don't do this, _my_ application looks shitty and > everyone will tell me. It's not the platform that gets a bad reputation, > it's my app. > > So, if anything should get paused, it's all applications which are not > white listed and which are not in the foreground. > > If I somehow missed the point, please tell me :) > > Cheers! > Conny > > > On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote: > > Hi, > > > > ext Eugene Antimirov wrote: > > >> It handles also audio policies and tries to make sure that you get > > >> your phone calls when the device is heavily loaded and some other > > >> minor things. > > > > > > Just to know. > > > > > > I see now this `ohmd` process in my 41-10. I did not get it, was this > > > daemon improved or made worse in new firmware released lately? > > > > Better for known (pre-installed) applications, worse for unknown > > applications. The reason for this is that unknown applications have > > unknown resource usage so system policy treats them with more care. > > > > > > It's a bit of a chicken and egg problem. Changing the policy is slow > > iterative work requiring lots of testing that the policy change doesn't > > significantly worsen other use-cases in some situations (e.g. for things > > for which there are certain certification & legal requirements). > > > > Developers can now experiment and report/discuss things which they would > > like policy to handle better (for certain classes of 3rd applications > > and their use-cases). I.e. in regards to 3rd party applications, the > > policies could be considered work-in-progress. > > > > > > Things that could potentially be done for 3rd party applications > > policy handling: > > > > - Default policy is improved in regards to unknown processes. > > It's yet unknown whether this can be done well enough without > > sacrificing the known functionality, that's why feedback is needed > > on the behavior of 3rd party application use-cases. > > > > - Applications themselves specify the required policy on install. > > This is extra work for apps, and requires extensive testing to > > guarantee that the policy they choose is good match for > > the application in all cases. (application doesn't leak or > > otherwise hog resources) > > > > - Some way for user to specify per-application policy. > > I'm sure power-users would like that... :-) > > > > > > - Eero > > _______________________________________________ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
