Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations
On Mon, 17 May 2021 at 23:54:01 +0200, Cyril Brulebois wrote:
> Simon McVittie <smcv@debian.org> (2021-05-17):
> > It looks as though the problem is that the size GTK chooses for a
> > GtkTextView (a debconf "note" or similar) is flapping between two
> > values.
>
> Without looking into the code, one might try and keep track of results
> that have been seen, and if N/N+1 is detected, maybe just assume this
> should be N+1 and move on with other computations? But anyway, further
> down your mail you seemed to have ideas already.
It wasn't obvious to me where we'd keep track of this, or how correct
it would be to do that - cache invalidation is reputed to be one of the
hardest problems in computer science, and this would be one more thing
that needs to be invalidated on at least those occasions when the layout
has legitimately changed (but without invalidating it too often because
that would destroy the workaround).
Having reproduced the English/rescue issue and got further with the
Sinhala/install issue with the GTK MR referenced below, I think it can
also happen that the layout flaps by an amount greater than 1 pixel
(I think the most I've seen is 4px), so a special case for n/n+1 isn't
going to be enough.
One of the reasons this took me a while is that I got distracted by the
difference I was seeing being exactly 1px, which I thought might be to
do with GTK adding 1px of extra width to make sure there's space for a
cursor - but after tracing through it, it seemed like GTK is always
adding/removing that width correctly.
> > My next thing to get a try when I get a chance will be to make GTK refuse
> > to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
> > outside that limit, with a g_warning().
This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2
The other thing I wanted to try was to make cdebconf create the GtkTextView
in an empty state, and then populate it with text a little later (perhaps
after layout but before drawing, or perhaps drawing one frame without text
and then adding the text in the next frame, I'm not actually sure). And
that also works:
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6
Following the rule of thumb that bad interactions between two components
should often be fixed on *both* sides, I'd be tempted to clone this bug,
reassign to both gtk+2.0 and cdebconf, and apply both changes.
As for Pango, I'm afraid figuring out whether it is doing something wrong
here is beyond my expertise. If I can characterize the maybe-bug in a clear
enough way I can try asking upstream - but as I said before, upstream will
be very reluctant to touch this as soon as I mention GTK 2, which has been
on life-support for a decade and is now officially dead.
smcv
Reply to: