Re: gtkwindow changes

[Tim Janik <timj gtk org>]

On 17 Aug 2001, Havoc Pennington wrote:

> 
> Tim Janik <timj gtk org> writes: 
> > ;) that's not the all-and-end of it, there're enough examples out there
> > that do:
> > 
> > model_set_foo (model, 10);
> > view_set_foo (view, 10); /* we know that most times we _get_ 10 from the model,
> >                           * and as model responses can take some time, updating
> >                           * here right away can greatly increase responsiveness
> >                           */
> > foo_changed_callback (new_foo)
> > {
> >   if (view->foo != new_foo)
> >     view_set_foo (view, new_foo);
> > }
> > 
> > why do you think there's code out there for various time consuming
> > tasks that implements precalculations and discarding mechanisms
> > for worst-case scenarios?
> > 
> 
> Bad, bad, bad hack. 
> 
> If your model is responding slowly, then this is awful, since there's
> user-visible flicker or jumping around or whatever in the view.
> There's no benefit to updating early to some guess vs. just keeping
> whatever your current value is until you know the real value.

nono, think e.g. pre-queueing of sound data and cancelation, people
don't do that because their machines/programs are too slow, but to avoid
dropouts/lags/etc and saving processor time by reduction of context switches
where possible. that usually results in better overall performance.
with your line of reasoning, basically any kind of precalculation or
anticipated caching behaviour suddenly becomes illegitimate.
think index generation for databases, jit compilation, branch prediction,
read-aheads of any kind...
i can't subscribe to this at all.

> Plus if your model is too slow to be useable, you need to fix it, not
> add bad hacks that try to make it 1% better.

this is not about making things 1% better, but to anticipate events
with high probability.

> If your model isn't responding too slowly, then there's no point in
> doing this stuff. For toplevel windows, the model definitely isn't
> responding too slowly; window resizing works just fine.

introducing always-queue policy for toplevels did have a noticable
effect on snapiness, and mind you, your processor will work "just fine"
without first and second level caches and bus prefetches and branch
prediction, it just won't work as fast. i'm not claiming window resizing
doesn't work, i'm claiming we can do better in responsiveness.

> Metacity will deny or modify configure requests pretty frequently;
> it's a perfectly legitimate thing to do. I'm sure other WM's also do
> so.
> 
> Anyhow, so let's get rid of RESIZE_IMMEDIATE for toplevels, unless
> someone has a reason to use it other than to demonstrate it doesn't
> work. ;-)

hey, it _does_ work after i fixed the recently introduced bugs ;)

> 
> Havoc
> 

---
ciaoTJ