bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre <vincent@vinc17.net>]

On 2020-11-01 18:15:04 +0200, Eli Zaretskii wrote:
> Interesting.  Once you understand where did the value 12 come from,
> perhaps you could see how things are different in a non-Cairo build.

It appears that Cairo uses floating point with poor rounding control
(see below). I suppose that the non-cairo driver keeps integers.

> Let me describe how row->phys_ascent is computed, so that you could
> take a closer look.
[...]

Yes, this is what I've found:

The row->phys_ascent comes from function display_line, in the loop
generating characters:

      if (/* Not a newline.  */
          nglyphs > 0
          /* Glyphs produced fit entirely in the line.  */
          && it->current_x < it->last_visible_x)
        {
[...]
          row->phys_ascent = max (row->phys_ascent, it->max_phys_ascent);
[...]
        }

At the first iteration, row->phys_ascent is changed from 0 to 12.
So, it comes from it->max_phys_ascent, which is set to 12 by

      PRODUCE_GLYPHS (it);

earlier in the loop. In this context (X protocol), this macro calls
gui_produce_glyphs (defined in xdisp.c).

In gui_produce_glyphs, this is case it->what == IT_CHARACTER, with
it->char_to_display == 'F'; pcm is true and it->phys_ascent is set
to 12 by

              it->phys_ascent = pcm->ascent + boff;

where pcm->ascent = 12 and boff = 0, while for Emacs without cairo,
pcm->ascent = 11 (and boff = 0) as expected.

With size 14 (with or without cairo), one has pcm->ascent = 12.

Thus the issue comes from pcm->ascent. It is set by get_per_char_metric,
where char2b = 40. With cairo, it calls function ftcrfont_text_extents
(defined in ftcrfont.c), which calls ftcrfont_glyph_extents, which sets
metrics->ascent to 12 from the cache.

When the cache is filled with

      cache->ascent = ceil (- extents.y_bearing);

extents.y_bearing (whose type is double) is equal to:

Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002
Font size 14: -0x1.8p+3 = -12

With ceil(), 11.000000000000002 rounds to 12, while the expected value
is 11. A rounding issue, as I guessed at

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#29

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)