[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ligatures
From: |
Pip Cet |
Subject: |
Re: Ligatures |
Date: |
Tue, 19 May 2020 16:16:53 +0000 |
On Tue, May 19, 2020 at 3:36 PM Eli Zaretskii <address@hidden> wrote:
> > From: Pip Cet <address@hidden>
> > Date: Tue, 19 May 2020 15:11:27 +0000
> > Cc: address@hidden, address@hidden
> >
> > On Tue, May 19, 2020 at 2:52 PM Eli Zaretskii <address@hidden> wrote:
> > > Btw, there's one subtle issue that will need to be resolved if we are
> > > to have this feature of "sub-glyph" cursor movement inside composed
> > > characters. The way we currently display the default block cursor is
> > > by simply redrawing the glyph at point in reverse video. So we don't
> > > have a way of displaying a cursor that "covers" only part of a glyph.
> >
> > I thought that was what glyph_row->clip was for.
>
> We could use that, but that's not the main problem.
Sorry, I genuinely don't understand what the problem is. draw_glyphs
is called by draw_phys_cursor_glyph, so all we need is a line or two
of extra code in draw_phys_cursor_glyphs to set row->clip to the
rectangle surrounding the subglyph the cursor is on. No further change
of the display engine is required for that, is it?
> The problem is that we need to change how the cursor is drawn, from
> the control flow POV.
That's a separate thing that, yes, we need to do. Because optimizing
for TTYs is no longer appropriate. But I don't see why we need to
perform this large change before performing the little one that makes
things work for subglyphs.
> We'd need to audit the code and see that the
> information required for drawing the cursor is available when we are
> drawing the text. And then there's the popular use case where nothing
> changes except the cursor position, in which case no text is redrawn
> at all.
Except for the glyphs the cursor is on, right? Those are redrawn by
draw_phys_cursor_glyph, or am I missing something here?
> > > To make this happen, we'd probably need to draw the cursor as part of
> > > drawing the glyph foreground and/or background, which is against the
> >
> > I believe that's a change we should make anyway: late cursor drawing
> > makes sense on TTYs with physical cursors, but on GUI backends, we
> > should simply use a special face for drawing the struct glyph a cursor
> > is on, IMHO.
>
> It cannot be a single face, because the "thing under cursor" can be
> anything, and can have different colors.
Agreed.
> We will need to merge faces,
> which is slower than the current simple but effective method, which
> completely sidesteps the issue.
I believe performance concerns are an entirely different subject (put
briefly, my opinion is that we've painted ourselves into a corner by
micro-optimizing fast loops over an essentially inefficient basic
design).
> in any case, using a face doesn't solve the main problem, as we'd
> still need to draw the glyph with partial colors.
Which we can do by setting glyph_row->clip? I don't see how there's
any problem here at all.
Again, I see three totally separate problems here:
1. draw a box cursor over a partial glyph
2. improve the display engine to handle cursor(s) like other
highlighting on graphical terminals
3. identify and counteract actual performance problems in the redisplay engine
I still don't see how (1) depends on (2), and I think I disagree with
you on the subject of (3), because I think we need to fix the design
first, moving a lot of C code out to Lisp, then see where things
actually chafe and maybe move some special code back to C.
- Re: Ligatures, (continued)
- Re: Ligatures, Werner LEMBERG, 2020/05/19
- Re: Ligatures, tomas, 2020/05/19
- Re: Ligatures, Eli Zaretskii, 2020/05/19
- Re: Ligatures, Eli Zaretskii, 2020/05/19
- Re: Ligatures, Pip Cet, 2020/05/19
- Re: Ligatures, Eli Zaretskii, 2020/05/19
- Re: Ligatures,
Pip Cet <=
- Re: Ligatures, Eli Zaretskii, 2020/05/19
- Re: Ligatures, Eli Zaretskii, 2020/05/19
- Re: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY), Julius Pfrommer, 2020/05/17
- Re: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY), Eli Zaretskii, 2020/05/17
- Re: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY), chad, 2020/05/17
- Re: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY), Alan Third, 2020/05/18