On Mon, 17 May 2021 at 18:12:35 +0200, Cyril Brulebois wrote: > And for those not following #debian-boot, I'm finding myself between a > rock and a hard place, as both options (trying to work around the > rendering-related hangs versus switching to GTK 3 at the last moment) > are very far from ideal… I'm not sure what we'll end up doing, and I'm > happy to get some “votes” pro or against any of those options, and to > hear about other options entirely.
My instinct is that it's far, far too late to be moving to GTK 3 this cycle, and I'd prefer to get a suitable hack into GTK 2 if we can find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting the installed system. I think d-i will need to move to GTK 3 early in the Debian 12 cycle, but hard freeze is not the time to be fast-forwarding through 10 years of GUI library development. I've continued to look into GTK2/Pango with some rather extensive printf debugging. I have other responsibilities and I'm trying to learn how GTK/Pango text layout works from first principles (I'm in the GNOME team but not really a GUI developer), so it's slow going, but I have some ideas for things that might be able to break the loop. It's not clear to me yet whether this is a GTK 2 bug, or a Pango bug, or what. GNOME team members who actually know what they're doing are welcome to step in any time. Upstream are going to be incredibly reluctant to help us with GTK 2, given that it has been deprecated in favour of GTK 3 for a decade, and is officially EOL now that GTK 4 has stable releases. Pango does seem like it's doing the wrong thing here, but perhaps GTK 2 or cdebconf is holding it wrong. Getting https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4 into cdebconf would make this easier, although we can revert it for the sake of a smaller diff once we think we have a solution if the release team are grumpy about it. Philip Hands wanted to get this running under automated testing, but my current GTK 2 and Pango patches are spamming the syslog at 3 million lines a minute when they get into the loop, so we're going to have logistical difficulties in saving logs. 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. GTK asks Pango "if you wrap lines at width x, how much space will you need?", then uses the result to re-run the layout algorithm, which changes the width available, which causes the layout algorithm to be re-run and so on. Under normal circumstances, this runs for a few iterations and then stabilizes at one size, terminating the loop, but when I select Sinhala from the language menu, the width flaps between 71 and 72 pixels, with each re-layout resulting in the other width. I think this might be related to the fact that when the layout is calculated at the narrower width, Pango decides that there isn't space to put the "." at the end of a paragraph on the same line as the last word, and so wraps it to the next line, which is fine; except that you'd expect the space required for the last word to get a bit smaller when the "." is not included, but actually Pango tells GTK that it will need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it flapping between the narrower and wider width. I don't know why that happens - perhaps the Indic shaper is drawing a character at the end of a line more elaborately, or something? However, either 71 or 72 pixels seems a ridiculous width to be trying to squish multiple sentences into, so arguably it's a bug in GTK 2's layout algorithm that it is even considering that as a size. The GTK 2 layout algorithm does not necessarily make much sense, and the fact that it can feed back into itself is probably a GTK 2 design flaw. During the GTK 3 cycle it was redone to be in terms of "height for width" (if I give you this width, how much height will you need? the mode cdebconf will end up using) and "width for height" (the opposite, rarely used) - so hopefully GTK 3 avoids this failure mode. However, it also seems wrong that telling Pango that less width is available can result in it saying it needs *more* minimum width, and maybe preventing this from happening would get GTK 2 to do the right thing. 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 might result in the text being clipped at the right margin (or left margin in Hebrew/Arabic), or even having its "ink rectangle" overlap with the next widget to the right (or left); but for d-i, which always uses the full screen width and in practice has a generous amount of space for its text, we might get away with it? In a very brief test that seemed to resolve the Sinhala thing, but I haven't tried the other paths that lead to infinite loops. Please could someone who has tried the other scenarios provide a walkthrough? If you want to replicate my super-verbose printf debugging: * https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4 * apply https://people.debian.org/~smcv/bug987587/20210516/gtk+2.0/ to gtk+2.0 (the patch to d/rules applies directly, the patch to GTK applies via d/patches) * apply https://people.debian.org/~smcv/bug987587/20210516/pango/ to pango1.0 * repeat test steps that I previously sent to this bug * look at the syslog and despair * you will want to truncate the syslog before repeating debugging, and send some strategic SIGSTOP to the debconf process when not actively letting it run, because otherwise the initramfs will run out of RAM I'll send a separate reply to -boot about the possibility of moving to GTK 3. smcv
