From 85ad8616007e286c237bb2906d1928bb551462e7 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Wed, 23 Feb 2022 15:07:59 +0200 Subject: [PATCH] ; * src/xterm.c: Minor fixes of the commentary. --- src/xterm.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/xterm.c b/src/xterm.c index a3c3c6f3f45..4b463da5f8e 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -117,9 +117,10 @@ along with GNU Emacs. If not, see . */ background pixel values. Usually, one graphics context is computed for each face when it is - first about to be displayed, and this graphics context is the one - which is used for future X drawing operations in a glyph string - with that face. (See `prepare_face_for_display' in xfaces.c). + about to be displayed for the first time, and this graphics context + is the one which is used for future X drawing operations in a glyph + string with that face. (See `prepare_face_for_display' in + xfaces.c). However, when drawing glyph strings for special display elements such as the cursor, or mouse sensitive text, different GCs may be @@ -155,11 +156,11 @@ along with GNU Emacs. If not, see . */ onto the physical display. When the visual class is TrueColor, the colormap will be indexed - based on the red, green, and blue components of the pixel values, - and the colormap will be statically allocated as to contain linear - ramps for each component. As such, most of the color allocation - described below is bypassed, and the pixel values are computed - directly from the color. + based on the red, green, and blue (RGB) components of the pixel + values, and the colormap will be statically allocated so as to + contain linear ramps for each component. As such, most of the + color allocation described below is bypassed, and the pixel values + are computed directly from the color. Otherwise, each time Emacs wants a pixel value that corresponds to a color, Emacs has to ask the X server to obtain the pixel value -- 2.39.5