[maemo-developers] Bug#6203, rotation and OHMD

[From: Kimmo Hämäläinen]

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 at maemo.org
> > https://lists.maemo.org/mailman/listinfo/maemo-developers
> 
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers