[Top][All Lists]

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

Re: Cursor drawing

From: Eli Zaretskii
Subject: Re: Cursor drawing
Date: Thu, 20 Dec 2018 21:35:46 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 20 Dec 2018 14:18:22 -0500
> > So maybe you should say more about how you imagine this works, and how
> > under that mental model you envision this part:
> >> - redraw of a clipping region is done by "rendering" the corresponding
> >>   part of a glyph matrix combined with the corresponding part of the
> >>   overlay layer into pixels.
> I imagine this as being done possibly as;
> 1- draw the relevant glyphs from the glyph matrix
> 2- draw the relevant part of the overlay on top of it (with some form of
>    transparency so as not to completely overwrite what was drawn in step 1).
> > The crucial part here, for me, is how this "combination" would be
> > different from "shoehorning crosshairs into the glyph matrix".  Can
> > you elaborate on what you had in mind?
> The crosshairs don't need to be represented/mentioned in the glyph matrix.
> You can just keep in the overlay layer an entry that says "draw vertical
> line at pixel column X" and "draw horizontal line at pixel line Y".

Then this can be done today, without any changes in the architecture
of the display engine.  Any code can draw whatever it wants on top of
what the "normal" window/frame-update code did.  The transparency
issue aside, you will just overwrite portions of the displayed text
according to the pixels you splat on the glass.

IOW, if we take the "fake cursors" as an example, the code which
implements them should just be moved outside of the functions called
from redisplay_window, and into a separate function which will be
called, say, by the frame_up_to_date_hook.

The disadvantage of this is, of course, that the code that draw the
face cursors will be needed to be implemented 4 times, one each for
every terminal-specific backend we support.

> >> The advantage would be mostly that the overlay data structure could be
> >> designed completely differently from glyph-matrices
> > Like what, for example?
> Maybe more like an SVG canvas?

You got me here: I have no idea how that works.

reply via email to

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