Re: gtkwindow changes

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> 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.

Precomputation is not the same at all. The code in all those examples
is not even trying to use an MVC pattern. 

But I'm not saying optimizations are always wrong; I'm saying this
particular one is useless. We don't need branch prediction for window
sizes. ;-)
 
> this is not about making things 1% better, but to anticipate events
> with high probability.

... in order to make things 1% better. ;-) I'm still not convinced we
even make things better, since in some cases it would cause strange
flicker.
 
> hey, it _does_ work after i fixed the recently introduced bugs ;)

My concern is that it only works by accident; I didn't write the code
thinking it would work, and I don't really want to maintain the code
promising that it will work. It introduces a whole new code path to
code that's already too complex.

Anyhow, thinking more about need_default_position = FALSE in
gtk_window_move_resize(), I believe it breaks the case where you call
gtk_window_set_position() or change the window's size requisition
between the initial gtk_window_move_resize() and mapping the window.

The reason I think this change is a hack is that
gtk_window_compute_configure_request() computes the current configure
request; prior to mapping, our configure request should _always_
include this default position calculation. So the real root cause of
the problem is that we somehow get in an infinite loop when this
default position calculation is done. I think setting
need_default_position to FALSE is a band-aid that changes the
semantics of compute_configure_request in order to work around some
other issue.

That's why I ask, what is the exact infinite loop (what is the
sequence of events that occur, which functions are being called)?

Havoc