Bas Wijnen <shevek <at> fmf.nl>
2005-12-05 11:16:39 GMT
On Sun, Dec 04, 2005 at 01:49:34PM -0500, Jonathan S. Shapiro wrote:
> On Sat, 2005-12-03 at 09:30 +0100, Bas Wijnen wrote:
> > On Fri, Dec 02, 2005 at 01:41:53PM -0500, Jonathan S. Shapiro wrote:
> > >
> > > 2. Tuning knobs: app gives jaggy video, user turns a quality knob.
> > What I mean by settings for the user really is 2, except that 2 seems very
> > window-oriented. The point I'm making is that the user may want something
> > to get resources which isn't in the foreground. For real-time video this
> > is obviously not the case, but computationally intensive tasks are often
> > uninteresting until they're done. Consider a fractal generator. If you
> > want generation to be fast, you minimize the window so it doesn't waste
> > time on drawing intermediate states. It is not desirable if that means
> > the generation is even slower because much of its resources are revoked.
> I don't agree. First, there is no reason to imagine that tuning knobs are
> limited to visible windows, so I don't really agree with that concern.
Ok, in that case my "settings" really is your option 2.
> Second, I don't agree with the background fractal example. If the user puts
> the fractal generator in the background and then starts a movie, they are
> saying "my attention is on the movie". I think that the principle here is
> that real time guarantees have to do with responding in a timely fashion
> where the focus of attention is. The background fractal problem may be a
> motivator for a high priority, but it is *not* a motivator for a real time
Oh, I wasn't talking about real-time guarantees. I was just saying that the
user should have the option to specify that one process is the most important