[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35468: [PATCH] Refactor draw_glyph_string on X and w32

From: Alan Third
Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32
Date: Fri, 3 May 2019 22:12:36 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

On Thu, May 02, 2019 at 12:14:10PM -0600, Alex Gramiak wrote:
> Alan Third <address@hidden> writes:
> > It looks exactly the same to me with or without the code. Perhaps I’d
> > see something different if I was using some theme which defined mouse
> > face differently.
> >
> > I really don’t see any reason why NS should behave differently from
> > the other terms here.
> There's a similar block in ns_maybe_dumpglyphs_background. Could you
> test with that block removed as well? Also, there's a conditional check
> (s->hl != DRAW_CURSOR) there that's not present in the other versions;
> could you see if that's necessary?

Removing the block in ns_maybe_dumpglyphs_background seems to make no
difference here. Removing the DRAW_CURSOR check results in the cursor
being drawn as a blank (background colour) rectangle on occasion.

I’m not sure what the difference is, but there are a couple of
comments in nsterm.m which reference NS drawing the cursor differently
to other terms, i.e.

  /* We draw the cursor (with NSRectFill), then draw the glyph on top
     (other terminals do it the other way round).  We must set
     w->phys_cursor_width to the cursor width.  For bar cursors, that
     is CURSOR_WIDTH; for box cursors, it is the glyph width.  */


  /* NOTE: under NS this is NOT used to draw cursors, but we must avoid
     overwriting cursor (usually when cursor on a tab).  */

and I suspect this check is related.
Alan Third

reply via email to

[Prev in Thread] Current Thread [Next in Thread]