* Emacs canvas support [not found] <875zdikdge.fsf.ref@yahoo.com> @ 2020-04-29 6:34 ` Po Lu via Emacs development discussions. 2020-04-29 8:24 ` Eli Zaretskii 2020-04-29 20:48 ` Juri Linkov 0 siblings, 2 replies; 53+ messages in thread From: Po Lu via Emacs development discussions. @ 2020-04-29 6:34 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 301 bytes --] I'd appreciate some feedback on something I came up with during my spare time: Emacs canvas support. For now it only works on X11 + Cairo builds, and I haven't quite figured out how to make redisplay work reliably on canvases, but it already seems to be quite promising. A patch is attached below. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Canvas patche --] [-- Type: text/x-patch, Size: 61624 bytes --] diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index e53f0e9f60..2a24576620 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -27,6 +27,7 @@ Display * Window Dividers:: Separating windows visually. * Display Property:: Images, margins, text size, etc. * Images:: Displaying images in Emacs buffers. +* Canvases:: Drawing areas inside Emacs buffers. * Xwidgets:: Displaying native widgets in Emacs buffers. * Buttons:: Adding clickable buttons to Emacs buffers. * Abstract Display:: Emacs's Widget for Object Collections. @@ -6509,6 +6510,152 @@ Image Cache debugging. @end defvar +@node Canvases +@cindex drawing canvases +@cindex drawing areas +@cindex canvases +@section Canvases + +This chapter describes canvases, objects that can store drawing operations +which are then displayed inside buffer text. + +@menu +* Creating Canvases:: How canvases can be created +* Operating on Canvases:: How canvases can be used +* Displaying Canvases:: How canvases can be displayed +@end menu + +@node Creating Canvases +@cindex creating Canvases +@pindex make-canvas + + This section describes how canvases can be created. +To create a canvas, call the function @code{make-canvas}. + +@defun make-canvas width height +This function takes 2 arguments @code{width}, and @code{height}, +and creates a canvas @code{width} wide and @code{height} tall. +@end defun + +@defun canvas-from-image image &optional width height +This function creates a canvas from the image descriptor +@code{image}. The created canvas will be @code{width} wide, +and @code{height} tall, if specified. +@end defun + +@node Operating on Canvases +@cindex operating on Canvases +@pindex canvas-rectangle + + This section describes how canvases can be drawn to, +and manipulated. + +@defun canvasp canvas +Return whether @code{canvas} is a canvas or not. +@end defun + +@defun canvas-dimensions canvas +Return the dimensions of @code{canvas} as a pair. +@end defun + +@defun canvas-ellipse canvas x y width height &optional color + hollow opacity +Draw an ellipse centred upon @code{x}, @code{y} onto the canvas +@code{canvas}. The drawn ellipse will be colored @code{color}, +or the current frame's foreground color if @code{color} is not +specified or nil. The opacity of the drawn item will be +@code{opacity}, and the item will be hollow if @code{hollow} is +non-nil. +@end defun + +@defun canvas-rectangle canvas x y width height &optional color + hollow opacity +Draw a rectangle at @code{x}, and @code{y} onto the canvas +@code{canvas}. The rectangle will be colored @code{color}, +or the current frame's foreground color if @code{color} is nil. +The opacity of the drawn item will be @code{opacity}, and the item +will be hollow if @code{hollow} is non-nil. +@end defun + +@defun canvas-fill-pixel canvas x y color opacity +Fill the pixel at @code{x}, @code{y} inside @code{canvas} +to @code{color}, with the opacity @code{opacity}. +@end defun + +@defun canvas-draw-string canvas x y string + &optional color opacity family size +Draw the string @code{string} to @code{x}, @code{y} +inside the canvas @code{canvas}. The font family used +will be @code{family}, the color @code{color}, the opacity +@code{opacity}, and the size @code{size}. + +@code{family} can either be a string, or a list in which +the first element should be the family as a string, the +second element should be whether the font should be italic, +and an optional third argument describing whether or not +the font should be bold. +@end defun + +@defun canvas-draw-image canvas image-spec x y + &optional width height frame opacity +Paint @code{image-spec} into @code{canvas} at @code{x}, +@code{y}. If @code{width} or @code{height} +is set and the image is wider than @code{width} or @code{height} respectively, +the image will be cropped to fit. The alpha channel of @code{image-spec} +will be set to @code{opacity}. +@end defun + +@defun canvas-measure-string canvas string &optional family size +Return a cons pair containing the width and height of @code{string}, +when rendered onto @code{canvas}, with the font @code{family} at +@code{size}. +@end defun + +@defun canvas-rounded-rectangle canvas x y width height radius + &optional color hollow opacity +Draw a rounded rectangle at @code{x}, @code{y} onto @code{canvas}. +The opacity of the rectangle will be @code{opacity}. +The radius of the rectangle will be @code{radius}. +@end defun + +@defun canvas-pixel-at canvas x y +Return the pixel at @code{x}, @code{y} inside @code{canvas}, +as an ARGB list. +@end defun + +@defun canvas-draw-canvas canvas canvas2 x y &optional width height opacity +Draw @code{canvas2} onto @code{canvas} at @code{x}, @code{y}. +@code{canvas2}'s alpha channel will be set to @code{opacity}, +if specified. +@code{canvas2} will not be taller than @code{height} or wider than +@code{width}, if specified. +@end defun + +@defun canvas-width canvas +Return the width of @code{canvas}. +@end defun + +@defun canvas-height canvas +Return the height of @code{canvas}. +@end defun + +@defun canvas-region canvas x y width height +Return a subsection of @code{canvas} at @code{x}, +@code{y}, that is @code{width} wide and @code{height} tall. +@end defun + +@defun canvas-arc canvas x y radius angle1 angle2 &optional color opacity +Draw an arc at @code{x}, @code{y}, with a radius of @code{radius}, +and the angles @code{angle1}, @code{angle2}. +@end defun + +@node Displaying Canvases +@cindex displaying Canvases + + Canvases can be displayed by setting them as the +@code{display} property of a string. + + @node Xwidgets @section Embedded Native Widgets @cindex xwidget diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index bba1b63115..d995ec4606 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -1430,6 +1430,7 @@ Top * Window Dividers:: Separating windows visually. * Display Property:: Enabling special display features. * Images:: Displaying images in Emacs buffers. +* Canvases:: Drawing areas inside Emacs buffers. * Buttons:: Adding clickable buttons to Emacs buffers. * Abstract Display:: Emacs's Widget for Object Collections. * Blinking:: How Emacs shows the matching open parenthesis. diff --git a/lisp/canvas.el b/lisp/canvas.el new file mode 100644 index 0000000000..d60d3efa4f --- /dev/null +++ b/lisp/canvas.el @@ -0,0 +1,49 @@ +;;; canvas.el --- Canvas support for GNU Emacs + +;; Copyright (C) 2020 Free Software Foundation, Inc. + +;; This file is part of GNU Emacs. + +;; GNU Emacs is free software: you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation, either version 3 of the License, or +;; (at your option) any later version. + +;; GNU Emacs is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. + +;; You should have received a copy of the GNU General Public License +;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. + +;;; Commentary: + +;;; These are several utlity functions for canvas operations that can +;;; be implemented in Lisp code. + +\f +;;; Code: + +(defun canvas-fill-pixel (canvas x y color opacity) + "Set the pixel at X, Y inside CANVAS to COLOR, with the opacity OPACITY." + (canvas-rectangle canvas x y 1 1 color opacity)) + +(defun canvas-from-image (image &optional width height) + "Create a canvas from IMAGE. +The canvas will be no wider than WIDTH (if specified), +and no taller than HEIGHT (if specified)." + (let ((canvas (make-canvas (or width (car (image-size image t))) + (or height (cdr (image-size image t)))))) + (prog1 canvas (canvas-draw-image canvas image 0 0)))) + +(defun canvas-width (canvas) + "Return the width of CANVAS." + (car (canvas-dimensions canvas))) + +(defun canvas-height (canvas) + "Return the height of CANVAS." + (cdr (canvas-dimensions canvas))) + +(provide 'canvas) +;;; canvas.el ends here diff --git a/lisp/loadup.el b/lisp/loadup.el index 97525b2708..1a9b1c7410 100644 --- a/lisp/loadup.el +++ b/lisp/loadup.el @@ -285,6 +285,8 @@ (load "emacs-lisp/tabulated-list") (load "buff-menu") +(load "canvas") + (if (fboundp 'x-create-frame) (progn (load "fringe") diff --git a/src/Makefile.in b/src/Makefile.in index 552dd2e50a..0d70c68b04 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -407,6 +407,7 @@ .m.o: ## be dumped as pure by dump-emacs. base_obj = dispnew.o frame.o scroll.o xdisp.o menu.o $(XMENU_OBJ) window.o \ charset.o coding.o category.o ccl.o character.o chartab.o bidi.o \ + common-canvas.o \ $(CM_OBJ) term.o terminal.o xfaces.o $(XOBJ) $(GTK_OBJ) $(DBUS_OBJ) \ emacs.o keyboard.o macros.o keymap.o sysdep.o \ bignum.o buffer.o filelock.o insdel.o marker.o \ diff --git a/src/alloc.c b/src/alloc.c index cc9ba8dbf5..acce0109e1 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -47,6 +47,7 @@ Copyright (C) 1985-1986, 1988, 1993-1995, 1997-2020 Free Software #include "blockinput.h" #include "pdumper.h" #include "termhooks.h" /* For struct terminal. */ +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ @@ -3114,6 +3115,11 @@ cleanup_vector (struct Lisp_Vector *vector) module_finalize_function (function); } #endif + else if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_CANVAS)) + { + struct canvas *cnvs = (struct canvas *) vector; + destroy_canvas_contents (cnvs->canvas); + } } /* Reclaim space used by unmarked vectors. */ diff --git a/src/canvas.h b/src/canvas.h new file mode 100644 index 0000000000..c42a15e6fd --- /dev/null +++ b/src/canvas.h @@ -0,0 +1,83 @@ +/* Canvas support for GNU Emacs. + Copyright (C) 2020 Free Software Foundation, Inc. + +This file is part of GNU Emacs. + +GNU Emacs is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or (at +your option) any later version. + +GNU Emacs is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */ + +#include <config.h> + +#include "lisp.h" +#include "frame.h" +#include "window.h" + +#ifdef USE_CAIRO +#include <cairo/cairo.h> +typedef cairo_surface_t *canvas_contents_t; +#else +typedef void *canvas_contents_t; +#endif + +struct canvas +{ + union vectorlike_header header; + Lisp_Object cnvs_objects; + Lisp_Object window; + Lisp_Object object; + + canvas_contents_t canvas; + int width, height; + bool multiple_objects_seen; + bool changed_since_last_redisplay; +} GCALIGNED_STRUCT; + +/* Test for xwidget pseudovector. */ +#define CANVASP(x) PSEUDOVECTORP (x, PVEC_CANVAS) +#define XCANVAS(a) \ + (eassert (CANVASP (a)), XUNTAG (a, Lisp_Vectorlike, struct canvas)) + +#define CHECK_CANVAS(x) CHECK_TYPE (CANVASP (x), Qcanvasp, x) + +#define MARK_CANVAS_CHANGED(x) \ + (((x)->changed_since_last_redisplay = true), \ + (windows_or_buffers_changed = 2), (redisplay ())); \ + do \ + { \ + if ((x)->multiple_objects_seen || !EQ (selected_window, (x)->window)) \ + { \ + Lisp_Object tail, head; \ + FOR_EACH_FRAME (tail, head) \ + { \ + struct frame *f = XFRAME (head); \ + SET_FRAME_GARBAGED (f); \ + } \ + } \ + } \ + while (false) + +extern Lisp_Object +make_canvas (int width, int height); + +extern canvas_contents_t +make_canvas_contents (int width, int height); + +extern void +destroy_canvas_contents (canvas_contents_t contents); + +extern void +syms_of_canvas (void); + +extern void +canvas_end_redisplay (struct window *w, + struct glyph_matrix *matrix); diff --git a/src/common-canvas.c b/src/common-canvas.c new file mode 100644 index 0000000000..501f4930f7 --- /dev/null +++ b/src/common-canvas.c @@ -0,0 +1,856 @@ +/* Canvas support for GNU Emacs. + Copyright (C) 2020 Free Software Foundation, Inc. + +This file is part of GNU Emacs. + +GNU Emacs is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or (at +your option) any later version. + +GNU Emacs is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */ + +#include "canvas.h" +#include "coding.h" + +#include <math.h> + +Lisp_Object +make_canvas (int width, int height) +{ +#ifndef USE_CAIRO + error ("Canvases are not supported without cairo.") +#endif + struct canvas *canvas = ALLOCATE_PSEUDOVECTOR + (struct canvas, object, PVEC_CANVAS); + canvas->width = width; + canvas->height = height; + canvas->object = Qnil; + canvas->multiple_objects_seen = false; + canvas->canvas = make_canvas_contents (width, height); + canvas->changed_since_last_redisplay = true; + + Lisp_Object cnvs; + XSETCANVAS (cnvs, canvas); + return cnvs; +} + +void +destroy_canvas_contents (canvas_contents_t contents) +{ +#ifdef USE_CAIRO + cairo_surface_destroy (contents); +#else + error ("Not implemented"); +#endif +} + +canvas_contents_t +make_canvas_contents (int width, int height) +{ +#ifdef USE_CAIRO + cairo_surface_t *crs = + cairo_image_surface_create (CAIRO_FORMAT_ARGB32, width, height); + return crs; +#else + error ("Not implemented"); +#endif +} + +void +canvas_end_redisplay (struct window *w, + struct glyph_matrix *matrix) +{ + int i; + int area; + + for (i = 0; i < matrix->nrows; ++i) + { + struct glyph_row *row; + row = MATRIX_ROW (matrix, i); + if (row->enabled_p) + for (area = LEFT_MARGIN_AREA; area < LAST_AREA; ++area) + { + struct glyph *glyph = row->glyphs[area]; + struct glyph *glyph_end = glyph + row->used[area]; + for (; glyph < glyph_end; ++glyph) + if (glyph->type == CANVAS_GLYPH && + glyph->u.canvas->changed_since_last_redisplay) + { + canvas_update_glyph + (w, i, row, area, row->glyphs[area] - + glyph, 1 + row->glyphs[area] - glyph, + glyph); + } + } + } +} + +DEFUN ("make-canvas", Fmake_canvas, Smake_canvas, 2, 2, 0, + doc: /* Create a canvas, WIDTH pixels wide, and HEIGHT pixels tall. */) + (Lisp_Object width, Lisp_Object height) +{ + check_integer_range (height, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + + return make_canvas (XFIXNUM (width), XFIXNUM (height)); +} + +DEFUN ("canvas-ellipse", Fcanvas_ellipse, Scanvas_ellipse, 5, 8, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall ellipse centred at X, Y in CANVAS. +The color of the ellipse will be COLOR (or the foreground color of COLOR is nil). +The ellipse will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object color, + Lisp_Object hollow, Lisp_Object opacity) +{ + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_matrix_t save_matrix; + cairo_get_matrix (cr, &save_matrix); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_scale (cr, 1, 1); + cairo_new_path (cr); + cairo_arc (cr, 0, 0, + XFIXNUM (width) / 2.0, 0, 2 * M_PI); + cairo_set_matrix (cr, &save_matrix); + + cairo_set_line_width (cr, canvas_stroke_width); + if (!NILP (hollow)) + cairo_stroke (cr); + else + cairo_fill (cr); + + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); +#endif + return Qnil; +} + +DEFUN ("canvasp", Fcanvasp, Scanvasp, 1, 1, 0, + doc: /* Return t if CANVAS is a canvas, else nil. */) + (Lisp_Object canvas) +{ + return CANVASP (canvas) ? Qt : Qnil; +} + +DEFUN ("canvas-rectangle", Fcanvas_rectangle, Scanvas_rectangle, 5, 8, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall rectangle at X, Y in CANVAS. +The color of the rectangle will be COLOR (or the foreground color of COLOR is nil). +The rectangle will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object color, + Lisp_Object hollow, Lisp_Object opacity) +{ + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + if (NILP (hollow)) + { + cairo_rectangle (cr, XFIXNUM (x), XFIXNUM (y), XFIXNUM (width), + XFIXNUM (height)); + cairo_fill (cr); + } + else + { + cairo_rectangle (cr, XFIXNUM (x), XFIXNUM (y), XFIXNUM (width), + XFIXNUM (height)); + cairo_stroke (cr); + } + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); + return Qnil; +#else + error ("Not implemented"); +#endif +} + +DEFUN ("canvas-rounded-rectangle", Fcanvas_rounded_rectangle, Scanvas_rounded_rectangle, 6, MANY, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall rectangle at X, Y in CANVAS. +The color of the rectangle will be COLOR (or the foreground color of COLOR is nil). +The rectangle will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. +usage: (canvas-rounded-rectangle canvas x y width height radius &optional color hollow opacity) */) + (ptrdiff_t nargs, Lisp_Object *args) +{ + Lisp_Object canvas, x, y, width, height, radius, color, hollow, opacity; + canvas = args[0]; + x = args[1]; + y = args[2]; + width = args[3]; + height = args[4]; + radius = args[5]; + color = Qnil; + hollow = Qnil; + opacity = Qnil; + + if (nargs > 6) + color = args[6]; + if (nargs > 7) + hollow = args[7]; + if (nargs > 8) + opacity = args[8]; + if (nargs > 9) + xsignal2 (Qwrong_number_of_arguments, + Qcanvas_rounded_rectangle, + make_fixnum (nargs)); + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + { +#define radius XFLOATINT (radius) + double degrees = M_PI / 180.0; +#define width XFIXNUM (width) +#define height XFIXNUM (height) +#define x XFIXNUM (x) +#define y XFIXNUM (y) + cairo_new_sub_path (cr); + cairo_arc (cr, x + width - radius, y + radius, radius, -90 * degrees, 0 * degrees); + cairo_arc (cr, x + width - radius, y + height - radius, radius, 0 * degrees, 90 * degrees); + cairo_arc (cr, x + radius, y + height - radius, radius, 90 * degrees, 180 * degrees); + cairo_arc (cr, x + radius, y + radius, radius, 180 * degrees, 270 * degrees); + cairo_close_path (cr); +#undef radius +#undef y +#undef x +#undef height +#undef width + } +#undef radius + cairo_set_line_width (cr, canvas_stroke_width); + if (NILP (hollow)) + cairo_fill (cr); + else + cairo_stroke (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); + return Qnil; +#else + error ("Not implemented"); +#endif +} + +DEFUN ("canvas-draw-string", Fcanvas_draw_string, Scanvas_draw_string, 4, 8, 0, + doc: /* Draw the string STRING onto the canvas CANVAS at X, Y. +The opacity of the drawn text will be OPACITY, and the color of the drawn text will be COLOR. +The font-family used will be FAMILY, which can be a string or a list of +the font-family as a string, whether or not the the text should be italic, +and whether or not the text should be bold. +The size of the text will be SIZE, or the default text size if nil. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object string, + Lisp_Object color, Lisp_Object opacity, Lisp_Object family, Lisp_Object size) +{ + if (noninteractive) + error ("`canvas-draw-string' cannot be called when running in batch mode."); + if (NILP (opacity)) + opacity = make_float (1.0); + if (NILP (size)) + size = make_fixnum (FRAME_TEXT_HEIGHT (XFRAME (selected_frame))); + if (NILP (family)) + family = build_string ("monospace"); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (opacity); + if (!Flistp (family)) + CHECK_STRING (family); + CHECK_STRING (string); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *c = XCANVAS (canvas); + cairo_t *cr = cairo_create (c->canvas); + cairo_font_slant_t slant_flags = CAIRO_FONT_SLANT_NORMAL; + cairo_font_weight_t weight_flags = CAIRO_FONT_WEIGHT_NORMAL; + const char *family_utf8; + if (!NILP (Flistp (family))) + { + if (!NILP (CALLN (Flss, Flength (family), make_fixnum (2)))) + error ("Invalid font spec"); + else + { + int length = XFIXNUM (Flength (family)); + if (length > 3) + error ("Invalid font spec"); + Lisp_Object italic, bold; + CHECK_STRING_CAR (family); + family_utf8 = SSDATA (ENCODE_UTF_8 (XCAR (family))); + if (length == 3) + bold = XCAR (XCDR (XCDR (family))); + else + bold = Qnil; + italic = XCAR (XCDR (family)); + if (!NILP (italic)) + slant_flags = CAIRO_FONT_SLANT_ITALIC; + if (!NILP (bold)) + weight_flags = CAIRO_FONT_WEIGHT_BOLD; + } + } + else + { + family_utf8 = SSDATA (ENCODE_UTF_8 (family)); + } + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_select_font_face (cr, family_utf8, + slant_flags, + weight_flags); + cairo_set_font_size (cr, XFIXNUM (size)); + cairo_move_to (cr, XFIXNUM (x), XFIXNUM (y) + XFIXNUM (size)); + cairo_show_text (cr, SSDATA (ENCODE_UTF_8 (string))); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (c); + return Qnil; +#else + return Qnil; +#endif +} + +DEFUN ("canvas-measure-string", Fcanvas_measure_string, Scanvas_measure_string, 2, 4, 0, + doc: /* Return a pair containing the width and height of STRING, +if drawn on CANVAS with the family FAMILY at SIZE. */) +(Lisp_Object canvas, Lisp_Object string, Lisp_Object family, Lisp_Object size) +{ + if (noninteractive) + error ("`canvas-draw-string' cannot be called when running in batch mode."); + if (NILP (size)) + size = make_fixnum (FRAME_TEXT_HEIGHT (XFRAME (selected_frame))); + if (NILP (family)) + family = build_string ("cairo:monospace"); + CHECK_CANVAS (canvas); + + if (!Flistp (family)) + CHECK_STRING (family); + CHECK_STRING (string); +#ifdef USE_CAIRO + struct canvas *c = XCANVAS (canvas); + cairo_t *cr = cairo_create (c->canvas); + cairo_font_slant_t slant_flags = CAIRO_FONT_SLANT_NORMAL; + cairo_font_weight_t weight_flags = CAIRO_FONT_WEIGHT_NORMAL; + const char *family_utf8; + if (!NILP (Flistp (family))) + { + if (!NILP (CALLN (Flss, Flength (family), make_fixnum (2)))) + error ("Invalid font spec"); + else + { + int length = XFIXNUM (Flength (family)); + if (length > 3) + error ("Invalid font spec"); + Lisp_Object italic, bold; + CHECK_STRING_CAR (family); + family_utf8 = SSDATA (ENCODE_UTF_8 (XCAR (family))); + if (length == 3) + bold = XCAR (XCDR (XCDR (family))); + else + bold = Qnil; + italic = XCAR (XCDR (family)); + if (!NILP (italic)) + slant_flags = CAIRO_FONT_SLANT_ITALIC; + if (!NILP (bold)) + weight_flags = CAIRO_FONT_WEIGHT_BOLD; + } + } + else + { + family_utf8 = SSDATA (ENCODE_UTF_8 (family)); + } + cairo_select_font_face (cr, family_utf8, + slant_flags, + weight_flags); + cairo_set_font_size (cr, XFIXNUM (size)); + cairo_text_extents_t extents; + cairo_text_extents (cr, SSDATA (ENCODE_UTF_8 (string)), &extents); + cairo_destroy (cr); + return Fcons (make_fixnum (extents.width), + make_fixnum (extents.height)); +#else + return Qnil; +#endif +} + +DEFUN ("canvas-draw-image", Fcanvas_draw_image, Scanvas_draw_image, 4, 8, + 0, doc: /* Paint IMAGE_SPEC onto CANVAS, at X, Y. +If WIDTH or HEIGHT is set, and IMAGE is wider than WIDTH or taller than HEIGHT, +IMAGE_SPEC will be cropped to fit WIDTH and/or HEIGHT respectively. +FRAME should be a live frame. +The opacity of the drawn image will be OPACITY. */) + (Lisp_Object canvas, Lisp_Object image_spec, + Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, + Lisp_Object frame, Lisp_Object opacity) +{ + if (valid_image_p (image_spec)) + { + if (NILP (frame)) + frame = selected_frame; + struct frame *f = decode_window_system_frame (frame); + ptrdiff_t id = lookup_image (f, image_spec); + struct image *img = IMAGE_FROM_ID (f, id); + if (!img) + return Qnil; + if (img->load_failed_p) + return Qnil; + int iwidth = img->width + 2 * img->hmargin; + int iheight = img->height + 2 * img->vmargin; + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + check_integer_range (width, 0, INT_MAX); + if (NILP (height)) + height = make_fixnum (iheight); + check_integer_range (height, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + if (NILP (opacity)) + opacity = make_fixnum (1); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + cairo_surface_t *crs + = cairo_image_surface_create_for_data ((unsigned char *) + img->pixmap->data, + (img->pixmap->bits_per_pixel + == 32 + ? CAIRO_FORMAT_RGB24 + : CAIRO_FORMAT_A8), + img->pixmap->width, + img->pixmap->height, + img->pixmap->bytes_per_line); + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_save (cr); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_rectangle (cr, 0, 0, + XFIXNUM (width), XFIXNUM (height)); + cairo_clip (cr); + cairo_set_source_surface (cr, crs, 0, 0); + cairo_paint_with_alpha (cr, XFLOATINT (opacity)); + cairo_restore (cr); + cairo_destroy (cr); + cairo_surface_destroy (crs); + MARK_CANVAS_CHANGED (cv); +#endif + } + else + error ("Invalid image specification"); + return Qnil; +} + +DEFUN ("canvas-arc", Fcanvas_arc, Scanvas_arc, 6, 8, 0, + doc: /* Draw an arc on CANVAS starting from XC, YC, +with a radius of RADIUS and 2 angles angle1 and angle2. +Use the color COLOR with the alpha channel set to OPACITY, if specified. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object radius, + Lisp_Object angle1, Lisp_Object angle2, Lisp_Object color, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (angle1); + CHECK_NUMBER (angle2); + CHECK_NUMBER (radius); + + if (NILP (opacity)) + opacity = make_fixnum (1.0); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame)) + ->query_colors (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + cairo_t *cr = cairo_create (XCANVAS (canvas)->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_arc (cr, XFLOATINT (x), XFLOATINT (y), XFLOATINT (radius), + XFLOATINT (angle1), XFLOATINT (angle2)); + cairo_stroke (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (XCANVAS (canvas)); +#else +#endif + return Qnil; +} + +DEFUN ("canvas-filled-arc", Fcanvas_filled_arc, Scanvas_filled_arc, 6, 8, 0, + doc: /* Draw a filled arc on CANVAS starting from XC, YC, +with a radius of RADIUS and 2 angles angle1 and angle2. +Use the color COLOR with the alpha channel set to OPACITY, if specified. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object radius, + Lisp_Object angle1, Lisp_Object angle2, Lisp_Object color, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (angle1); + CHECK_NUMBER (angle2); + CHECK_NUMBER (radius); + + if (NILP (opacity)) + opacity = make_fixnum (1.0); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame)) + ->query_colors (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + cairo_t *cr = cairo_create (XCANVAS (canvas)->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_arc (cr, XFLOATINT (x), XFLOATINT (y), XFLOATINT (radius), + XFLOATINT (angle1), XFLOATINT (angle2)); + cairo_fill (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (XCANVAS (canvas)); +#else +#endif + return Qnil; +} + +DEFUN ("canvas-region", Fcanvas_region, Scanvas_region, 5, 5, 0, + doc: /* Return a canvas containing a WIDTH wide and HEIGHT tall +subsection of CANVAS at X, Y */) + (Lisp_Object canvas, Lisp_Object x, + Lisp_Object y, Lisp_Object width, Lisp_Object height) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + +#ifdef USE_CAIRO + int ix = XFIXNUM (x), + iy = XFIXNUM (y), + iw = XFIXNUM (width), + ih = XFIXNUM (height); + cairo_surface_t *s = cairo_surface_create_for_rectangle + (XCANVAS (canvas)->canvas, ix, iy, iw, ih); + Lisp_Object newcvs = make_canvas (iw, ih); + struct canvas *target = XCANVAS (newcvs); + cairo_t *t = cairo_create (target->canvas); + cairo_set_source_surface (t, s, 0, 0); + cairo_paint (t); + cairo_destroy (t); + cairo_surface_destroy (s); + return newcvs; +#else + error ("Not implemented.") +#endif +} + + +DEFUN ("canvas-draw-canvas", Fcanvas_draw_canvas, Scanvas_draw_canvas, 4, 7, + 0, doc: /* Paint CANVAS2 onto CANVAS, at X, Y. +If WIDTH or HEIGHT is set, and IMAGE is wider than WIDTH or taller than HEIGHT, +IMAGE_SPEC will be cropped to fit WIDTH and/or HEIGHT respectively. +The opacity of the drawn image will be OPACITY. */) + (Lisp_Object canvas, Lisp_Object canvas2, + Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + CHECK_CANVAS (canvas2); + int iwidth = XCANVAS (canvas2)->width; + int iheight = XCANVAS (canvas2)->height; + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + check_integer_range (width, 0, INT_MAX); + if (NILP (height)) + height = make_fixnum (iheight); + check_integer_range (height, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + if (NILP (opacity)) + opacity = make_fixnum (1); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + cairo_surface_t *crs = XCANVAS (canvas2)->canvas; + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_save (cr); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_rectangle (cr, 0, 0, XFIXNUM (width), XFIXNUM (height)); + cairo_clip (cr); + cairo_set_source_surface (cr, crs, 0, 0); + cairo_paint_with_alpha (cr, XFLOATINT (opacity)); + cairo_restore (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); +#endif + return Qnil; +} + +DEFUN ("canvas-pixel-at", Fcanvas_pixel_at, Scanvas_pixel_at, 3, 3, 0, + doc: /* Return the color of the pixel at X, Y inside CANVAS as an ARGB list. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y) +{ +#ifndef USE_CAIRO + error ("Not implemented."); +#else + CHECK_CANVAS (canvas); + check_integer_range (x, 0, XCANVAS (canvas)->width); + check_integer_range (y, 0, XCANVAS (canvas)->height); + struct { +#ifdef WORDS_BIGENDIAN + uint8_t a, r, g, b; +#else + uint8_t b, g, r, a; +#endif + } *argb32 = + (void *) cairo_image_surface_get_data (XCANVAS (canvas)->canvas); + typeof (*argb32) res = argb32 [XFIXNUM (y) * XCANVAS (canvas)->width + + XFIXNUM (x)]; + return CALLN (Flist, make_fixnum (res.a), + make_fixnum (res.r), + make_fixnum (res.g), + make_fixnum (res.b)); +#endif +} + +DEFUN ("canvas-dimensions", Fcanvas_dimensions, Scanvas_dimensions, 1, 1, 0, + doc: /* Return a cons pair containing the width and height of CANVAS. */) + (Lisp_Object canvas) +{ + CHECK_CANVAS (canvas); + return Fcons (make_fixnum (XCANVAS (canvas)->width), + make_fixnum (XCANVAS (canvas)->height)); +} + +void +syms_of_canvas (void) +{ + defsubr (&Smake_canvas); + defsubr (&Scanvas_rectangle); + defsubr (&Scanvas_ellipse); + defsubr (&Scanvas_rectangle); + defsubr (&Scanvas_draw_string); + defsubr (&Scanvas_draw_image); + defsubr (&Scanvas_draw_canvas); + defsubr (&Scanvas_measure_string); + defsubr (&Scanvas_dimensions); + defsubr (&Scanvas_region); + defsubr (&Scanvas_pixel_at); + defsubr (&Scanvas_arc); + defsubr (&Scanvasp); + defsubr (&Scanvas_filled_arc); + defsubr (&Scanvas_rounded_rectangle); + DEFSYM (Qcanvas_rounded_rectangle, "canvas-rounded-rectangle"); + DEFSYM (Qcanvasp, "canvasp"); + DEFSYM (Qcolor_values, "color-values"); + DEFVAR_INT ("canvas-stroke-width", canvas_stroke_width, + doc: /* The stroke width to be used in canvases. */); + canvas_stroke_width = 4; +} diff --git a/src/data.c b/src/data.c index bce2e53cfb..aefd6d7e70 100644 --- a/src/data.c +++ b/src/data.c @@ -263,6 +263,8 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, return Qxwidget; case PVEC_XWIDGET_VIEW: return Qxwidget_view; + case PVEC_CANVAS: + return Qcanvas; /* "Impossible" cases. */ case PVEC_MISC_PTR: case PVEC_OTHER: @@ -3859,6 +3861,7 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qchar_table, "char-table"); DEFSYM (Qbool_vector, "bool-vector"); DEFSYM (Qhash_table, "hash-table"); + DEFSYM (Qcanvas, "canvas"); DEFSYM (Qthread, "thread"); DEFSYM (Qmutex, "mutex"); DEFSYM (Qcondition_variable, "condition-variable"); diff --git a/src/dispextern.h b/src/dispextern.h index 0b1f3d14ae..d33b87c3df 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -382,7 +382,10 @@ #define SET_GLYPH_FROM_GLYPH_CODE(glyph, gc) \ STRETCH_GLYPH, /* Glyph is an external widget drawn by the GUI toolkit. */ - XWIDGET_GLYPH + XWIDGET_GLYPH, + + /* Glyph is a canvas. */ + CANVAS_GLYPH }; @@ -540,6 +543,9 @@ #define FACE_ID_BITS 20 struct xwidget *xwidget; #endif + /* Canvas reference (type == CANVAS_GLYPH). */ + struct canvas *canvas; + /* Sub-structure for type == STRETCH_GLYPH. */ struct { @@ -1405,6 +1411,9 @@ #define OVERLAPS_ERASED_CURSOR (1 << 2) /* Xwidget. */ struct xwidget *xwidget; + /* Canvas. */ + struct canvas *canvas; + /* Slice */ struct glyph_slice slice; @@ -2158,7 +2167,10 @@ #define MAX_FRINGE_BITMAPS (1<<FRINGE_ID_BITS) IT_CONTINUATION, /* Xwidget. */ - IT_XWIDGET + IT_XWIDGET, + + /* Canvas. */ + IT_CANVAS }; @@ -2223,6 +2235,7 @@ #define MAX_FRINGE_BITMAPS (1<<FRINGE_ID_BITS) GET_FROM_IMAGE, GET_FROM_STRETCH, GET_FROM_XWIDGET, + GET_FROM_CANVAS, NUM_IT_METHODS }; @@ -2447,6 +2460,10 @@ #define OVERLAY_STRING_CHUNK_SIZE 16 struct { Lisp_Object object; } xwidget; + /* method == GET_FROM_CANVAS */ + struct { + Lisp_Object object; + } canvas; } u; /* Current text and display positions. */ @@ -2578,6 +2595,9 @@ #define OVERLAY_STRING_CHUNK_SIZE 16 /* If what == IT_XWIDGET. */ struct xwidget *xwidget; + /* If what == IT_CANVAS. */ + struct canvas *canvas; + /* Values from `slice' property. */ struct it_slice slice; @@ -3714,6 +3734,11 @@ #define IMAGE_BACKGROUND_TRANSPARENT(img, f, mask) \ #endif /* HAVE_WINDOW_SYSTEM */ +extern void +canvas_update_glyph (struct window *w, int x, struct glyph_row *row, + enum glyph_row_area area, ptrdiff_t start, ptrdiff_t end, + struct glyph *glyph); + INLINE_HEADER_END #endif /* not DISPEXTERN_H_INCLUDED */ diff --git a/src/dispnew.c b/src/dispnew.c index 5b6fa51a56..1ba639cb79 100644 --- a/src/dispnew.c +++ b/src/dispnew.c @@ -43,6 +43,7 @@ Copyright (C) 1985-1988, 1993-1995, 1997-2020 Free Software Foundation, #include "tparam.h" #include "xwidget.h" #include "pdumper.h" +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER @@ -3697,6 +3698,7 @@ update_window (struct window *w, bool force_p) #endif xwidget_end_redisplay (w, w->current_matrix); + canvas_end_redisplay (w, w->current_matrix); clear_glyph_matrix (desired_matrix); return paused_p; @@ -3782,6 +3784,7 @@ gui_update_window_end (struct window *w, bool cursor_on_p, FRAME_RIF (f)->update_window_end_hook (w, cursor_on_p, mouse_face_overwritten_p); + canvas_end_redisplay (w, w->current_matrix); } #endif /* HAVE_WINDOW_SYSTEM */ @@ -4371,6 +4374,11 @@ scrolling_window (struct window *w, int tab_line_p) return 0; #endif + /* We need this to fix canvas movement detection in a reliable way. + FIXME. */ + if (w->have_canvas_p) + return 0; + /* Give up if some rows in the desired matrix are not enabled. */ if (! MATRIX_ROW_ENABLED_P (desired_matrix, i)) return -1; @@ -5565,6 +5573,10 @@ mode_line_string (struct window *w, enum window_part part, y0 -= row->ascent - glyph->ascent; } #endif + if (glyph->type == CANVAS_GLYPH) + { + y0 -= row->ascent - glyph->ascent; + } } else { @@ -5654,6 +5666,10 @@ marginal_area_string (struct window *w, enum window_part part, y0 += glyph->slice.img.y; } #endif + if (glyph->type == CANVAS_GLYPH) + { + y0 -= row->ascent - glyph->ascent; + } } else { diff --git a/src/emacs.c b/src/emacs.c index ea9c4cd79d..c16af2c14c 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -94,6 +94,8 @@ #define MAIN_PROGRAM #include "getpagesize.h" #include "gnutls.h" +#include "canvas.h" + #ifdef PROFILING # include <sys/gmon.h> extern void moncontrol (int mode); @@ -1567,6 +1569,8 @@ main (int argc, char **argv) /* Before init_window_once, because it sets up the Vcoding_system_hash_table. */ syms_of_coding (); /* This should be after syms_of_fileio. */ + + syms_of_canvas (); init_frame_once (); /* Before init_window_once. */ init_window_once (); /* Init the window system. */ #ifdef HAVE_WINDOW_SYSTEM diff --git a/src/lisp.h b/src/lisp.h index b4ac017dcf..f463399dad 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1103,6 +1103,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) PVEC_MUTEX, PVEC_CONDVAR, PVEC_MODULE_FUNCTION, + PVEC_CANVAS, /* These should be last, for internal_equal and sxhash_obj. */ PVEC_COMPILED, @@ -1349,6 +1350,7 @@ #define XSETSUB_CHAR_TABLE(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_SUB_CHAR_TABLE)) #define XSETTHREAD(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_THREAD)) #define XSETMUTEX(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_MUTEX)) #define XSETCONDVAR(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_CONDVAR)) +#define XSETCANVAS(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_CANVAS)) /* Efficiently convert a pointer to a Lisp object and back. The pointer is represented as a fixnum, so the garbage collector diff --git a/src/pdumper.c b/src/pdumper.c index 63424c5734..33c527c7d8 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -3036,6 +3036,8 @@ dump_vectorlike (struct dump_context *ctx, error_unsupported_dump_object (ctx, lv, "condvar"); case PVEC_MODULE_FUNCTION: error_unsupported_dump_object (ctx, lv, "module function"); + case PVEC_CANVAS: + error_unsupported_dump_object (ctx, lv, "canvas"); default: error_unsupported_dump_object(ctx, lv, "weird pseudovector"); } diff --git a/src/print.c b/src/print.c index bd1769144e..28a620fd20 100644 --- a/src/print.c +++ b/src/print.c @@ -34,6 +34,7 @@ Copyright (C) 1985-1986, 1988, 1993-1995, 1997-2020 Free Software #include "blockinput.h" #include "xwidget.h" #include "dynlib.h" +#include "canvas.h" #include <c-ctype.h> #include <float.h> @@ -1833,6 +1834,16 @@ print_vectorlike (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag, } break; #endif + case PVEC_CANVAS: + { + print_c_string ("#<canvas ", printcharfun); + const struct canvas *canvas = XCANVAS (obj); + print_object (make_fixnum (canvas->width), printcharfun, false); + printchar ('x', printcharfun); + print_object (make_fixnum (canvas->height), printcharfun, false); + print_c_string (">", printcharfun); + } + break; default: emacs_abort (); diff --git a/src/window.c b/src/window.c index e2dea8b70e..5e0ed1ab94 100644 --- a/src/window.c +++ b/src/window.c @@ -4289,6 +4289,7 @@ make_window (void) w->scroll_bar_width = -1; w->scroll_bar_height = -1; w->column_number_displayed = -1; + w->have_canvas_p = false; /* Reset window_list. */ Vwindow_list = Qnil; /* Return window. */ diff --git a/src/window.h b/src/window.h index 167d1be7ab..67c7417007 100644 --- a/src/window.h +++ b/src/window.h @@ -445,6 +445,9 @@ #define WINDOW_H_INCLUDED window. */ bool_bf suspend_auto_hscroll : 1; + /* True if we think a canvas is being displayed in this window. */ + bool_bf have_canvas_p : 1; + /* Amount by which lines of this window are scrolled in y-direction (smooth scrolling). */ int vscroll; diff --git a/src/xdisp.c b/src/xdisp.c index 140d134572..e63c497100 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -462,6 +462,7 @@ Copyright (C) 1985-1988, 1993-1995, 1997-2020 Free Software Foundation, #include "fontset.h" #include "blockinput.h" #include "xwidget.h" +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ @@ -1055,6 +1056,7 @@ #define THIN_SPACE_WIDTH 1 static bool next_element_from_image (struct it *); static bool next_element_from_stretch (struct it *); static bool next_element_from_xwidget (struct it *); +static bool next_element_from_canvas (struct it *); static void load_overlay_strings (struct it *, ptrdiff_t); static bool get_next_display_element (struct it *); static enum move_it_result @@ -2688,7 +2690,7 @@ remember_mouse_glyph (struct frame *f, int gx, int gy, NativeRectangle *rect) if (g < end) { - if (g->type == IMAGE_GLYPH) + if (g->type == IMAGE_GLYPH || g->type == CANVAS_GLYPH) { /* Don't remember when mouse is over image, as image may have hot-spots. */ @@ -5589,7 +5591,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, /* After this point, VALUE is the property after any margin prefix has been stripped. It must be a string, - an image specification, or `(space ...)'. + an image specification, a canvas, or `(space ...)'. LOCATION specifies where to display: `left-margin', `right-margin' or nil. */ @@ -5601,7 +5603,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, #endif /* not HAVE_WINDOW_SYSTEM */ || (CONSP (value) && EQ (XCAR (value), Qspace)) || ((it ? FRAME_WINDOW_P (it->f) : frame_window_p) - && valid_xwidget_spec_p (value))); + && valid_xwidget_spec_p (value))) || CANVASP (value); if (valid_p && display_replaced == 0) { @@ -5686,6 +5688,22 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, *position = start_pos; it->xwidget = lookup_xwidget (value); } + else if (CANVASP (value)) + { + it->what = IT_CANVAS; + it->method = GET_FROM_CANVAS; + it->position = start_pos; + it->object = NILP (object) ? it->w->contents : object; + *position = start_pos; + it->canvas = XCANVAS (value); + if ((!NILP (it->canvas->object) && + !EQ (it->canvas->object, it->object)) || + (!NILP (it->canvas->window) && + XWINDOW (it->canvas->window) != it->w)) + it->canvas->multiple_objects_seen = true; + it->canvas->object = it->object; + XSETWINDOW (it->canvas->window, it->w); + } #ifdef HAVE_WINDOW_SYSTEM else { @@ -6446,6 +6464,9 @@ push_it (struct it *it, struct text_pos *position) case GET_FROM_XWIDGET: p->u.xwidget.object = it->object; break; + case GET_FROM_CANVAS: + p->u.canvas.object = it->object; + break; case GET_FROM_BUFFER: case GET_FROM_DISPLAY_VECTOR: case GET_FROM_STRING: @@ -6550,6 +6571,9 @@ pop_it (struct it *it) case GET_FROM_XWIDGET: it->object = p->u.xwidget.object; break; + case GET_FROM_CANVAS: + it->object = p->u.canvas.object; + break; case GET_FROM_STRETCH: it->object = p->u.stretch.object; break; @@ -7236,6 +7260,7 @@ reseat_to_string (struct it *it, const char *s, Lisp_Object string, next_element_from_image, next_element_from_stretch, next_element_from_xwidget, + next_element_from_canvas, }; #define GET_NEXT_DISPLAY_ELEMENT(it) (*get_next_element[(it)->method]) (it) @@ -8151,6 +8176,7 @@ set_iterator_to_next (struct it *it, bool reseat_p) case GET_FROM_IMAGE: case GET_FROM_STRETCH: case GET_FROM_XWIDGET: + case GET_FROM_CANVAS: /* The position etc with which we have to proceed are on the stack. The position may be at the end of a string, @@ -8619,6 +8645,12 @@ next_element_from_xwidget (struct it *it) return true; } +static bool +next_element_from_canvas (struct it *it) +{ + it->what = IT_CANVAS; + return true; +} /* Fill iterator IT with next display element from a stretch glyph property. IT->object is the value of the text property. Value is @@ -27810,6 +27842,19 @@ fill_xwidget_glyph_string (struct glyph_string *s) s->xwidget = s->first_glyph->u.xwidget; } #endif + +static void +fill_canvas_glyph_string (struct glyph_string *s) +{ + eassert (s->first_glyph->type == CANVAS_GLYPH); + s->w->have_canvas_p = true; + s->face = FACE_FROM_ID (s->f, s->first_glyph->face_id); + s->font = s->face->font; + s->width = s->first_glyph->pixel_width; + s->ybase += s->first_glyph->voffset; + s->canvas = s->first_glyph->u.canvas; + s->canvas->changed_since_last_redisplay = false; +} /* Fill glyph string S from a sequence of stretch glyphs. START is the index of the first glyph to consider, @@ -28227,6 +28272,18 @@ #define BUILD_IMAGE_GLYPH_STRING(START, END, HEAD, TAIL, HL, X, LAST_X) \ while (false) #endif +#define BUILD_CANVAS_GLYPH_STRING(START, END, HEAD, TAIL, HL, X, LAST_X) \ + do \ + { \ + s = alloca (sizeof *s); \ + INIT_GLYPH_STRING (s, NULL, w, row, area, START, HL); \ + append_glyph_string (&(HEAD), &(TAIL), s); \ + ++(START); \ + s->x = (X); \ + fill_canvas_glyph_string (s); \ + } \ + while (false) + /* Add a glyph string for a sequence of character glyphs to the list of strings between HEAD and TAIL. START is the index of the first glyph in row area AREA of glyph row ROW that is part of the new @@ -28378,7 +28435,11 @@ #define BUILD_GLYPH_STRINGS_1(START, END, HEAD, TAIL, HL, X, LAST_X) \ case IMAGE_GLYPH: \ BUILD_IMAGE_GLYPH_STRING (START, END, HEAD, TAIL, \ HL, X, LAST_X); \ - break; + break; \ + case CANVAS_GLYPH: \ + BUILD_CANVAS_GLYPH_STRING (START, END, HEAD, TAIL, \ + HL, X, LAST_X); \ + break; \ #define BUILD_GLYPH_STRINGS_XW(START, END, HEAD, TAIL, HL, X, LAST_X) \ case XWIDGET_GLYPH: \ @@ -29086,6 +29147,116 @@ produce_image_glyph (struct it *it) } } +static void +produce_canvas_glyph (struct it *it) +{ + struct canvas *canvas; + int glyph_ascent, crop; + + eassert (it->what == IT_CANVAS); + + struct face *face = FACE_FROM_ID (it->f, it->face_id); + prepare_face_for_display (it->f, face); + + canvas = it->canvas; + it->ascent = it->phys_ascent = glyph_ascent = canvas->height / 2; + it->descent = it->phys_descent = canvas->height / 2; + it->pixel_width = canvas->width; + + if (it->descent < 0) + it->descent = 0; + + it->nglyphs = 1; + + if (face->box != FACE_NO_BOX) + { + if (face->box_horizontal_line_width > 0) + { + it->ascent += face->box_horizontal_line_width; + it->descent += face->box_horizontal_line_width; + } + + if (face->box_vertical_line_width > 0) + { + if (it->start_of_box_run_p) + it->pixel_width += face->box_vertical_line_width; + it->pixel_width += face->box_vertical_line_width; + } + } + + take_vertical_position_into_account (it); + + /* Automatically crop wide image glyphs at right edge so we can + draw the cursor on same display row. */ + crop = it->pixel_width - (it->last_visible_x - it->current_x); + if (crop > 0 && (it->hpos == 0 || it->pixel_width > it->last_visible_x / 4)) + it->pixel_width -= crop; + + if (it->glyph_row) + { + enum glyph_row_area area = it->area; + struct glyph *glyph + = it->glyph_row->glyphs[area] + it->glyph_row->used[area]; + + if (it->glyph_row->reversed_p) + { + struct glyph *g; + + /* Make room for the new glyph. */ + for (g = glyph - 1; g >= it->glyph_row->glyphs[it->area]; g--) + g[1] = *g; + glyph = it->glyph_row->glyphs[it->area]; + } + if (glyph < it->glyph_row->glyphs[area + 1]) + { + glyph->charpos = CHARPOS (it->position); + glyph->object = it->object; + glyph->pixel_width = clip_to_bounds (-1, it->pixel_width, SHRT_MAX); + glyph->ascent = glyph_ascent; + glyph->descent = it->descent; + glyph->voffset = it->voffset; + glyph->type = CANVAS_GLYPH; + glyph->avoid_cursor_p = it->avoid_cursor_p; + glyph->multibyte_p = it->multibyte_p; + glyph->u.canvas = it->canvas; + if (it->glyph_row->reversed_p && area == TEXT_AREA) + { + /* In R2L rows, the left and the right box edges need to be + drawn in reverse direction. */ + glyph->right_box_line_p = it->start_of_box_run_p; + glyph->left_box_line_p = it->end_of_box_run_p; + } + else + { + glyph->left_box_line_p = it->start_of_box_run_p; + glyph->right_box_line_p = it->end_of_box_run_p; + } + glyph->overlaps_vertically_p = 0; + glyph->padding_p = 0; + glyph->glyph_not_available_p = 0; + glyph->face_id = it->face_id; + glyph->font_type = FONT_TYPE_UNKNOWN; + if (it->bidi_p) + { + glyph->resolved_level = it->bidi_it.resolved_level; + eassert ((it->bidi_it.type & 7) == it->bidi_it.type); + glyph->bidi_type = it->bidi_it.type; + } + ++it->glyph_row->used[area]; + } + else + IT_EXPAND_MATRIX_WIDTH (it, area); + } +} + +void +canvas_update_glyph (struct window *w, int x, struct glyph_row *row, + enum glyph_row_area area, ptrdiff_t start, ptrdiff_t end, + struct glyph *glyph) +{ + draw_glyphs (w, x, row, area, start, end, DRAW_NORMAL_TEXT, 0); +} + static void produce_xwidget_glyph (struct it *it) { @@ -30608,6 +30779,8 @@ gui_produce_glyphs (struct it *it) produce_stretch_glyph (it); else if (it->what == IT_XWIDGET) produce_xwidget_glyph (it); + else if (it->what == IT_CANVAS) + produce_canvas_glyph (it); done: /* Accumulate dimensions. Note: can't assume that it->descent > 0 @@ -31008,6 +31181,10 @@ get_window_cursor_type (struct window *w, struct glyph *glyph, int *width, cursor_type = HOLLOW_BOX_CURSOR; } } + if (glyph != NULL && glyph->type == CANVAS_GLYPH) + { + cursor_type = HOLLOW_BOX_CURSOR; + } return cursor_type; } diff --git a/src/xterm.c b/src/xterm.c index 7989cecec7..716ed0ef97 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -75,6 +75,7 @@ Copyright (C) 1989, 1993-2020 Free Software Foundation, Inc. #include "sysselect.h" #include "menu.h" #include "pdumper.h" +#include "canvas.h" #ifdef USE_X_TOOLKIT #include <X11/Shell.h> @@ -2066,6 +2067,30 @@ x_draw_glyphless_glyph_string_foreground (struct glyph_string *s) } } +static void +x_draw_canvas_glyph_string_foreground (struct glyph_string *s) +{ + eassert (s->first_glyph->type == CANVAS_GLYPH); +#ifdef USE_CAIRO + cairo_t *cr = x_begin_cr_clip (s->f, s->gc); + int x = s->x; + int y = s->ybase - s->first_glyph->ascent; + + if (s->face->box != FACE_NO_BOX && + s->first_glyph->left_box_line_p) + x += max (s->face->box_vertical_line_width, 0); + + x_set_glyph_string_clipping (s); + x_clear_area (s->f, x, y, s->width, s->height); + cairo_set_source_surface (cr, s->canvas->canvas, + s->x, s->y); + cairo_paint (cr); + x_end_cr_clip (s->f); +#else + emacs_abort (); +#endif +} + #ifdef USE_X_TOOLKIT #ifdef USE_LUCID @@ -3811,6 +3836,11 @@ x_draw_glyph_string (struct glyph_string *s) x_draw_glyphless_glyph_string_foreground (s); break; + case CANVAS_GLYPH: + x_draw_glyph_string_background (s, true); + x_draw_canvas_glyph_string_foreground (s); + break; + default: emacs_abort (); } ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 6:34 ` Emacs canvas support Po Lu via Emacs development discussions. @ 2020-04-29 8:24 ` Eli Zaretskii 2020-04-29 9:57 ` Po Lu 2020-04-29 20:48 ` Juri Linkov 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 8:24 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 14:34:09 +0800 > From: Po Lu via "Emacs development discussions." <emacs-devel@gnu.org> > > I'd appreciate some feedback on something I came up with during my spare > time: Emacs canvas support. I've read the code and the docs, but I don't think I have a clear idea of what "canvases" are and what would be their intended usage. Perhaps consider starting the documentation with some introductory comments and even a small tutorial. It sounds like you are talking about a way to create images dynamically, but then I don't understand why we need canvas-from-image, for example. Also, is there support for clicking the mouse on a canvas? I don't see it. > For now it only works on X11 + Cairo builds, and I haven't quite figured > out how to make redisplay work reliably on canvases Well, that'd be my main comments. I don't quite understand the parts of the display code you use for this, they seem like a copy/paste from other objects, sometimes with comments that weren't updated and still reference images instead of canvases. If the drawing on the canvas is supposed to be modified by Lisp code, then we'd need a much more elaborate machinery than just one flag to decide when a canvas needs to be redrawn. Thanks. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 8:24 ` Eli Zaretskii @ 2020-04-29 9:57 ` Po Lu 2020-04-29 10:10 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Po Lu @ 2020-04-29 9:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1847 bytes --] Eli Zaretskii <eliz@gnu.org> writes: > I've read the code and the docs, but I don't think I have a clear idea > of what "canvases" are and what would be their intended usage. > Perhaps consider starting the documentation with some introductory > comments and even a small tutorial. A canvas is an object that contains memory that can be painted to, and then displayed by setting it as the `display' text property. > It sounds like you are talking about a way to create images > dynamically, but then I don't understand why we need canvas-from-image, > for example. It's not really a way to create images dynamically, but rather paint to a section of the screen. `canvas-from-image' is just a convenience function that produces a paintable canvas from a static image. > Also, is there support for clicking the mouse on a canvas? I don't > see it. You can bind mouse events as usual. > Well, that'd be my main comments. I don't quite understand the parts > of the display code you use for this, they seem like a copy/paste from Correct, glyph production and iterator code code was mostly copied from the xwidgets code, since I was somewhat in a rush. Thanks for the feedback. > other objects, sometimes with comments that weren't updated and still > reference images instead of canvases. I'll fix that promptly. > If the drawing on the canvas is supposed to be modified by Lisp code, > then we'd need a much more elaborate machinery than just one flag to > decide when a canvas needs to be redrawn. Agreed, that is something I've been trying to figure out for some time now. Right now, I just do my best to figure out if the canvas has not touched anything important, and if it has, it just garbages each frame and calls redisplay. Attached is some sample code that should hopefully demonstrate exactly what they are capable of. [-- Attachment #2: canvas test --] [-- Type: text/plain, Size: 2879 bytes --] (setq canvas (make-canvas 1800 1800)) (erase-buffer) (insert (propertize " " 'display canvas)) (canvas-draw-image canvas (create-image "splash.png") 0 0 180 180 (selected-frame) 1.0) (canvas-ellipse canvas (/ 180 2) (/ 180 2) 130 130 "green") (canvas-rectangle canvas 0 0 180 180 "red" t) (canvas-rectangle canvas 20 20 40 100 "white" t 0.5) (canvas-draw-string canvas 0 0 "Hello, Emacs" "red" 1.0 "monospace" 50) (canvas-draw-string canvas 60 60 "Hello, Emacs" "white" 1.0 '("monospace" t t) 50) (let ((image (create-image "splash.png"))) (canvas-draw-image canvas image 700 20)) (setq track-mouse t) (defun mouse-movement-canvas-4-paint () "The function to be called when the mouse is moved." (interactive "") (track-mouse (let ((event)) (while (mouse-movement-p (setq event (read-event))) (let* ((position (event-start event)) (x (car (posn-x-y position))) (y (cdr (posn-x-y position)))) (message (format "%d %d" x y)) (canvas-filled-arc canvas x y 100.0 (* 45.0 (/ pi 180.0)) pi "blue")))))) (defun mouse-movement-canvas-paint () "The function to be called when the mouse is moved." (interactive "") (track-mouse (let ((event)) (while (mouse-movement-p (setq event (read-event))) (let* ((position (event-start event)) (x (car (posn-x-y position))) (y (cdr (posn-x-y position)))) (message (format "%d %d" x y)) (canvas-ellipse canvas x y 10 10 "blue")))))) (defun mouse-movement-3-canvas-paint () "The function to be called when the mouse is moved." (interactive "") (track-mouse (let ((event)) (while (mouse-movement-p (setq event (read-event))) (let* ((position (event-start event)) (x (car (posn-x-y position))) (y (cdr (posn-x-y position)))) (message (format "%d %d" x y)) (canvas-rectangle canvas x y 80 80 "white")))))) (defun mouse-movement-2-canvas-paint () "The function to be called when the mouse is moved." (interactive "") (track-mouse (let ((event)) (while (mouse-movement-p (setq event (read-event))) (let* ((position (event-start event)) (x (car (posn-x-y position))) (y (cdr (posn-x-y position)))) (message (format "%d %d" x y)) (canvas-draw-string canvas x y "Welcome to Emacs" nil nil nil 22)))))) (local-set-key [down-mouse-1] #'mouse-movement-canvas-paint) (local-set-key [down-mouse-3] #'mouse-movement-2-canvas-paint) (local-set-key [down-mouse-2] #'mouse-movement-3-canvas-paint) (local-set-key [C-down-mouse-1] #'mouse-movement-canvas-4-paint) (canvas-measure-string canvas "hi") (canvas-draw-string canvas 0 0 "Hi" "yellow") (setq canvas2 (canvas-from-image (create-image "splash.png"))) (canvas-rectangle canvas2 0 0 40 20 "orange") (canvas-rectangle canvas2 20 0 40 20 "black") (canvas-rounded-rectangle canvas 20 0 40 20 10.0 "red" nil) (canvas-draw-canvas canvas canvas2 500 500) ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 9:57 ` Po Lu @ 2020-04-29 10:10 ` Eli Zaretskii 2020-04-29 10:22 ` Po Lu 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 10:10 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 17:57:03 +0800 > > > I've read the code and the docs, but I don't think I have a clear idea > > of what "canvases" are and what would be their intended usage. > > Perhaps consider starting the documentation with some introductory > > comments and even a small tutorial. > > A canvas is an object that contains memory that can be painted to, and > then displayed by setting it as the `display' text property. That's the technical description of the implementation. It doesn't explain when canvases can be useful and for what purposes. > > It sounds like you are talking about a way to create images > > dynamically, but then I don't understand why we need canvas-from-image, > > for example. > > It's not really a way to create images dynamically, but rather paint to > a section of the screen. But the result of this painting is some graphical object, similar to an image, that will be displayed within a buffer, right? > > Also, is there support for clicking the mouse on a canvas? I don't > > see it. > > You can bind mouse events as usual. Did I miss the code that tells Emacs the click was on a canvas? E.g., if you click on a canvas, what does posn-object return when passed the click event as its argument? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:10 ` Eli Zaretskii @ 2020-04-29 10:22 ` Po Lu 2020-04-29 10:27 ` Po Lu via Emacs development discussions. 2020-04-29 10:35 ` Eli Zaretskii 0 siblings, 2 replies; 53+ messages in thread From: Po Lu @ 2020-04-29 10:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > That's the technical description of the implementation. It doesn't > explain when canvases can be useful and for what purposes. Canvases are useful for when I want to be able to control a portion of a screen dynamically, in a fast way, from Lisp code. For instance, displaying a constantly changing bar chart or graph inside Emacs. > But the result of this painting is some graphical object, similar to > an image, that will be displayed within a buffer, right? Correct. > Did I miss the code that tells Emacs the click was on a canvas? E.g., > if you click on a canvas, what does posn-object return when passed the > click event as its argument? Oops. I missed that. Thanks for bringing it up. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:22 ` Po Lu @ 2020-04-29 10:27 ` Po Lu via Emacs development discussions. 2020-04-29 11:47 ` Eli Zaretskii 2020-04-29 10:35 ` Eli Zaretskii 1 sibling, 1 reply; 53+ messages in thread From: Po Lu via Emacs development discussions. @ 2020-04-29 10:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 896 bytes --] Po Lu <luangruo@yahoo.com> writes: > Eli Zaretskii <eliz@gnu.org> writes: > > >> That's the technical description of the implementation. It doesn't >> explain when canvases can be useful and for what purposes. > > Canvases are useful for when I want to be able to control a portion of a > screen dynamically, in a fast way, from Lisp code. For instance, > displaying a constantly changing bar chart or graph inside Emacs. > >> But the result of this painting is some graphical object, similar to >> an image, that will be displayed within a buffer, right? > > Correct. > >> Did I miss the code that tells Emacs the click was on a canvas? E.g., >> if you click on a canvas, what does posn-object return when passed the >> click event as its argument? > > Oops. I missed that. Thanks for bringing it up. Here is a version of the patch with several of the problems you mentioned rectified. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-emacs-canvas-patches.diff --] [-- Type: text/x-patch, Size: 62494 bytes --] diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index e53f0e9f60..2a24576620 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -27,6 +27,7 @@ Display * Window Dividers:: Separating windows visually. * Display Property:: Images, margins, text size, etc. * Images:: Displaying images in Emacs buffers. +* Canvases:: Drawing areas inside Emacs buffers. * Xwidgets:: Displaying native widgets in Emacs buffers. * Buttons:: Adding clickable buttons to Emacs buffers. * Abstract Display:: Emacs's Widget for Object Collections. @@ -6509,6 +6510,152 @@ Image Cache debugging. @end defvar +@node Canvases +@cindex drawing canvases +@cindex drawing areas +@cindex canvases +@section Canvases + +This chapter describes canvases, objects that can store drawing operations +which are then displayed inside buffer text. + +@menu +* Creating Canvases:: How canvases can be created +* Operating on Canvases:: How canvases can be used +* Displaying Canvases:: How canvases can be displayed +@end menu + +@node Creating Canvases +@cindex creating Canvases +@pindex make-canvas + + This section describes how canvases can be created. +To create a canvas, call the function @code{make-canvas}. + +@defun make-canvas width height +This function takes 2 arguments @code{width}, and @code{height}, +and creates a canvas @code{width} wide and @code{height} tall. +@end defun + +@defun canvas-from-image image &optional width height +This function creates a canvas from the image descriptor +@code{image}. The created canvas will be @code{width} wide, +and @code{height} tall, if specified. +@end defun + +@node Operating on Canvases +@cindex operating on Canvases +@pindex canvas-rectangle + + This section describes how canvases can be drawn to, +and manipulated. + +@defun canvasp canvas +Return whether @code{canvas} is a canvas or not. +@end defun + +@defun canvas-dimensions canvas +Return the dimensions of @code{canvas} as a pair. +@end defun + +@defun canvas-ellipse canvas x y width height &optional color + hollow opacity +Draw an ellipse centred upon @code{x}, @code{y} onto the canvas +@code{canvas}. The drawn ellipse will be colored @code{color}, +or the current frame's foreground color if @code{color} is not +specified or nil. The opacity of the drawn item will be +@code{opacity}, and the item will be hollow if @code{hollow} is +non-nil. +@end defun + +@defun canvas-rectangle canvas x y width height &optional color + hollow opacity +Draw a rectangle at @code{x}, and @code{y} onto the canvas +@code{canvas}. The rectangle will be colored @code{color}, +or the current frame's foreground color if @code{color} is nil. +The opacity of the drawn item will be @code{opacity}, and the item +will be hollow if @code{hollow} is non-nil. +@end defun + +@defun canvas-fill-pixel canvas x y color opacity +Fill the pixel at @code{x}, @code{y} inside @code{canvas} +to @code{color}, with the opacity @code{opacity}. +@end defun + +@defun canvas-draw-string canvas x y string + &optional color opacity family size +Draw the string @code{string} to @code{x}, @code{y} +inside the canvas @code{canvas}. The font family used +will be @code{family}, the color @code{color}, the opacity +@code{opacity}, and the size @code{size}. + +@code{family} can either be a string, or a list in which +the first element should be the family as a string, the +second element should be whether the font should be italic, +and an optional third argument describing whether or not +the font should be bold. +@end defun + +@defun canvas-draw-image canvas image-spec x y + &optional width height frame opacity +Paint @code{image-spec} into @code{canvas} at @code{x}, +@code{y}. If @code{width} or @code{height} +is set and the image is wider than @code{width} or @code{height} respectively, +the image will be cropped to fit. The alpha channel of @code{image-spec} +will be set to @code{opacity}. +@end defun + +@defun canvas-measure-string canvas string &optional family size +Return a cons pair containing the width and height of @code{string}, +when rendered onto @code{canvas}, with the font @code{family} at +@code{size}. +@end defun + +@defun canvas-rounded-rectangle canvas x y width height radius + &optional color hollow opacity +Draw a rounded rectangle at @code{x}, @code{y} onto @code{canvas}. +The opacity of the rectangle will be @code{opacity}. +The radius of the rectangle will be @code{radius}. +@end defun + +@defun canvas-pixel-at canvas x y +Return the pixel at @code{x}, @code{y} inside @code{canvas}, +as an ARGB list. +@end defun + +@defun canvas-draw-canvas canvas canvas2 x y &optional width height opacity +Draw @code{canvas2} onto @code{canvas} at @code{x}, @code{y}. +@code{canvas2}'s alpha channel will be set to @code{opacity}, +if specified. +@code{canvas2} will not be taller than @code{height} or wider than +@code{width}, if specified. +@end defun + +@defun canvas-width canvas +Return the width of @code{canvas}. +@end defun + +@defun canvas-height canvas +Return the height of @code{canvas}. +@end defun + +@defun canvas-region canvas x y width height +Return a subsection of @code{canvas} at @code{x}, +@code{y}, that is @code{width} wide and @code{height} tall. +@end defun + +@defun canvas-arc canvas x y radius angle1 angle2 &optional color opacity +Draw an arc at @code{x}, @code{y}, with a radius of @code{radius}, +and the angles @code{angle1}, @code{angle2}. +@end defun + +@node Displaying Canvases +@cindex displaying Canvases + + Canvases can be displayed by setting them as the +@code{display} property of a string. + + @node Xwidgets @section Embedded Native Widgets @cindex xwidget diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index bba1b63115..d995ec4606 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -1430,6 +1430,7 @@ Top * Window Dividers:: Separating windows visually. * Display Property:: Enabling special display features. * Images:: Displaying images in Emacs buffers. +* Canvases:: Drawing areas inside Emacs buffers. * Buttons:: Adding clickable buttons to Emacs buffers. * Abstract Display:: Emacs's Widget for Object Collections. * Blinking:: How Emacs shows the matching open parenthesis. diff --git a/lisp/canvas.el b/lisp/canvas.el new file mode 100644 index 0000000000..d60d3efa4f --- /dev/null +++ b/lisp/canvas.el @@ -0,0 +1,49 @@ +;;; canvas.el --- Canvas support for GNU Emacs + +;; Copyright (C) 2020 Free Software Foundation, Inc. + +;; This file is part of GNU Emacs. + +;; GNU Emacs is free software: you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation, either version 3 of the License, or +;; (at your option) any later version. + +;; GNU Emacs is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. + +;; You should have received a copy of the GNU General Public License +;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. + +;;; Commentary: + +;;; These are several utlity functions for canvas operations that can +;;; be implemented in Lisp code. + +\f +;;; Code: + +(defun canvas-fill-pixel (canvas x y color opacity) + "Set the pixel at X, Y inside CANVAS to COLOR, with the opacity OPACITY." + (canvas-rectangle canvas x y 1 1 color opacity)) + +(defun canvas-from-image (image &optional width height) + "Create a canvas from IMAGE. +The canvas will be no wider than WIDTH (if specified), +and no taller than HEIGHT (if specified)." + (let ((canvas (make-canvas (or width (car (image-size image t))) + (or height (cdr (image-size image t)))))) + (prog1 canvas (canvas-draw-image canvas image 0 0)))) + +(defun canvas-width (canvas) + "Return the width of CANVAS." + (car (canvas-dimensions canvas))) + +(defun canvas-height (canvas) + "Return the height of CANVAS." + (cdr (canvas-dimensions canvas))) + +(provide 'canvas) +;;; canvas.el ends here diff --git a/lisp/loadup.el b/lisp/loadup.el index 97525b2708..1a9b1c7410 100644 --- a/lisp/loadup.el +++ b/lisp/loadup.el @@ -285,6 +285,8 @@ (load "emacs-lisp/tabulated-list") (load "buff-menu") +(load "canvas") + (if (fboundp 'x-create-frame) (progn (load "fringe") diff --git a/src/Makefile.in b/src/Makefile.in index 552dd2e50a..0d70c68b04 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -407,6 +407,7 @@ .m.o: ## be dumped as pure by dump-emacs. base_obj = dispnew.o frame.o scroll.o xdisp.o menu.o $(XMENU_OBJ) window.o \ charset.o coding.o category.o ccl.o character.o chartab.o bidi.o \ + common-canvas.o \ $(CM_OBJ) term.o terminal.o xfaces.o $(XOBJ) $(GTK_OBJ) $(DBUS_OBJ) \ emacs.o keyboard.o macros.o keymap.o sysdep.o \ bignum.o buffer.o filelock.o insdel.o marker.o \ diff --git a/src/alloc.c b/src/alloc.c index cc9ba8dbf5..acce0109e1 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -47,6 +47,7 @@ Copyright (C) 1985-1986, 1988, 1993-1995, 1997-2020 Free Software #include "blockinput.h" #include "pdumper.h" #include "termhooks.h" /* For struct terminal. */ +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ @@ -3114,6 +3115,11 @@ cleanup_vector (struct Lisp_Vector *vector) module_finalize_function (function); } #endif + else if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_CANVAS)) + { + struct canvas *cnvs = (struct canvas *) vector; + destroy_canvas_contents (cnvs->canvas); + } } /* Reclaim space used by unmarked vectors. */ diff --git a/src/canvas.h b/src/canvas.h new file mode 100644 index 0000000000..036f2bf499 --- /dev/null +++ b/src/canvas.h @@ -0,0 +1,83 @@ +/* Canvas support for GNU Emacs. + Copyright (C) 2020 Free Software Foundation, Inc. + +This file is part of GNU Emacs. + +GNU Emacs is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or (at +your option) any later version. + +GNU Emacs is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */ + +#include <config.h> + +#include "lisp.h" +#include "frame.h" +#include "window.h" + +#ifdef USE_CAIRO +#include <cairo/cairo.h> +typedef cairo_surface_t *canvas_contents_t; +#else +typedef void *canvas_contents_t; +#endif + +struct canvas +{ + union vectorlike_header header; + Lisp_Object cnvs_objects; + Lisp_Object window; + Lisp_Object object; + + canvas_contents_t canvas; + int width, height; + bool multiple_objects_seen; + bool changed_since_last_redisplay; +} GCALIGNED_STRUCT; + +/* Test for canvas pseudovector. */ +#define CANVASP(x) PSEUDOVECTORP (x, PVEC_CANVAS) +#define XCANVAS(a) \ + (eassert (CANVASP (a)), XUNTAG (a, Lisp_Vectorlike, struct canvas)) + +#define CHECK_CANVAS(x) CHECK_TYPE (CANVASP (x), Qcanvasp, x) + +#define MARK_CANVAS_CHANGED(x) \ + (((x)->changed_since_last_redisplay = true), \ + (windows_or_buffers_changed = 2), (redisplay ())); \ + do \ + { \ + if ((x)->multiple_objects_seen || !EQ (selected_window, (x)->window)) \ + { \ + Lisp_Object tail, head; \ + FOR_EACH_FRAME (tail, head) \ + { \ + struct frame *f = XFRAME (head); \ + SET_FRAME_GARBAGED (f); \ + } \ + } \ + } \ + while (false) + +extern Lisp_Object +make_canvas (int width, int height); + +extern canvas_contents_t +make_canvas_contents (int width, int height); + +extern void +destroy_canvas_contents (canvas_contents_t contents); + +extern void +syms_of_canvas (void); + +extern void +canvas_end_redisplay (struct window *w, + struct glyph_matrix *matrix); diff --git a/src/common-canvas.c b/src/common-canvas.c new file mode 100644 index 0000000000..329c37daad --- /dev/null +++ b/src/common-canvas.c @@ -0,0 +1,868 @@ +/* Canvas support for GNU Emacs. + Copyright (C) 2020 Free Software Foundation, Inc. + +This file is part of GNU Emacs. + +GNU Emacs is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or (at +your option) any later version. + +GNU Emacs is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */ + +#include "canvas.h" +#include "coding.h" + +#include <math.h> + +Lisp_Object +make_canvas (int width, int height) +{ +#ifndef USE_CAIRO + error ("Canvases are not supported without cairo.") +#endif + struct canvas *canvas = ALLOCATE_PSEUDOVECTOR + (struct canvas, object, PVEC_CANVAS); + canvas->width = width; + canvas->height = height; + canvas->object = Qnil; + canvas->multiple_objects_seen = false; + canvas->canvas = make_canvas_contents (width, height); + canvas->changed_since_last_redisplay = true; + + Lisp_Object cnvs; + XSETCANVAS (cnvs, canvas); + return cnvs; +} + +void +destroy_canvas_contents (canvas_contents_t contents) +{ +#ifdef USE_CAIRO + cairo_surface_destroy (contents); +#else + error ("Not implemented"); +#endif +} + +canvas_contents_t +make_canvas_contents (int width, int height) +{ +#ifdef USE_CAIRO + cairo_surface_t *crs = + cairo_image_surface_create (CAIRO_FORMAT_ARGB32, width, height); + return crs; +#else + error ("Not implemented"); +#endif +} + +void +canvas_end_redisplay (struct window *w, + struct glyph_matrix *matrix) +{ + int i; + int area; + + struct canvas **unmark_canvases; + ptrdiff_t unmark_size = 0; + unmark_canvases = xmalloc (sizeof *unmark_canvases * unmark_size); + + for (i = 0; i < matrix->nrows; ++i) + { + struct glyph_row *row; + row = MATRIX_ROW (matrix, i); + if (row->enabled_p) + for (area = LEFT_MARGIN_AREA; area < LAST_AREA; ++area) + { + struct glyph *glyph = row->glyphs[area]; + struct glyph *glyph_end = glyph + row->used[area]; + for (; glyph < glyph_end; ++glyph) + if (glyph->type == CANVAS_GLYPH && + glyph->u.canvas->changed_since_last_redisplay) + { + ++unmark_size; + unmark_canvases + = xrealloc (unmark_canvases, + (sizeof *unmark_canvases * unmark_size)); + unmark_canvases[unmark_size - 1] = glyph->u.canvas; + canvas_update_glyph + (w, i, row, area, row->glyphs[area] - + glyph, 1 + row->glyphs[area] - glyph, + glyph); + } + } + } + for (; unmark_size; unmark_size--) + unmark_canvases[unmark_size - 1]->changed_since_last_redisplay = false; + xfree (unmark_canvases); +} + +DEFUN ("make-canvas", Fmake_canvas, Smake_canvas, 2, 2, 0, + doc: /* Create a canvas, WIDTH pixels wide, and HEIGHT pixels tall. */) + (Lisp_Object width, Lisp_Object height) +{ + check_integer_range (height, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + + return make_canvas (XFIXNUM (width), XFIXNUM (height)); +} + +DEFUN ("canvas-ellipse", Fcanvas_ellipse, Scanvas_ellipse, 5, 8, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall ellipse centred at X, Y in CANVAS. +The color of the ellipse will be COLOR (or the foreground color of COLOR is nil). +The ellipse will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object color, + Lisp_Object hollow, Lisp_Object opacity) +{ + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_matrix_t save_matrix; + cairo_get_matrix (cr, &save_matrix); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_scale (cr, 1, 1); + cairo_new_path (cr); + cairo_arc (cr, 0, 0, + XFIXNUM (width) / 2.0, 0, 2 * M_PI); + cairo_set_matrix (cr, &save_matrix); + + cairo_set_line_width (cr, canvas_stroke_width); + if (!NILP (hollow)) + cairo_stroke (cr); + else + cairo_fill (cr); + + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); +#endif + return Qnil; +} + +DEFUN ("canvasp", Fcanvasp, Scanvasp, 1, 1, 0, + doc: /* Return t if CANVAS is a canvas, else nil. */) + (Lisp_Object canvas) +{ + return CANVASP (canvas) ? Qt : Qnil; +} + +DEFUN ("canvas-rectangle", Fcanvas_rectangle, Scanvas_rectangle, 5, 8, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall rectangle at X, Y in CANVAS. +The color of the rectangle will be COLOR (or the foreground color of COLOR is nil). +The rectangle will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object color, + Lisp_Object hollow, Lisp_Object opacity) +{ + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + if (NILP (hollow)) + { + cairo_rectangle (cr, XFIXNUM (x), XFIXNUM (y), XFIXNUM (width), + XFIXNUM (height)); + cairo_fill (cr); + } + else + { + cairo_rectangle (cr, XFIXNUM (x), XFIXNUM (y), XFIXNUM (width), + XFIXNUM (height)); + cairo_stroke (cr); + } + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); + return Qnil; +#else + error ("Not implemented"); +#endif +} + +DEFUN ("canvas-rounded-rectangle", Fcanvas_rounded_rectangle, Scanvas_rounded_rectangle, 6, MANY, 0, + doc: /* Draw a WIDTH wide and HEIGHT tall rectangle at X, Y in CANVAS. +The color of the rectangle will be COLOR (or the foreground color of COLOR is nil). +The rectangle will be hollow if HOLLOW is non-nil. +The opacity of the circle will be OPACITY, which should be a floating-point +number between 1 and 0. +usage: (canvas-rounded-rectangle canvas x y width height radius &optional color hollow opacity) */) + (ptrdiff_t nargs, Lisp_Object *args) +{ + Lisp_Object canvas, x, y, width, height, radius, color, hollow, opacity; + canvas = args[0]; + x = args[1]; + y = args[2]; + width = args[3]; + height = args[4]; + radius = args[5]; + color = Qnil; + hollow = Qnil; + opacity = Qnil; + + if (nargs > 6) + color = args[6]; + if (nargs > 7) + hollow = args[7]; + if (nargs > 8) + opacity = args[8]; + if (nargs > 9) + xsignal2 (Qwrong_number_of_arguments, + Qcanvas_rounded_rectangle, + make_fixnum (nargs)); + if (NILP (opacity)) + opacity = make_float (1.0); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + { +#define radius XFLOATINT (radius) + double degrees = M_PI / 180.0; +#define width XFIXNUM (width) +#define height XFIXNUM (height) +#define x XFIXNUM (x) +#define y XFIXNUM (y) + cairo_new_sub_path (cr); + cairo_arc (cr, x + width - radius, y + radius, radius, -90 * degrees, 0 * degrees); + cairo_arc (cr, x + width - radius, y + height - radius, radius, 0 * degrees, 90 * degrees); + cairo_arc (cr, x + radius, y + height - radius, radius, 90 * degrees, 180 * degrees); + cairo_arc (cr, x + radius, y + radius, radius, 180 * degrees, 270 * degrees); + cairo_close_path (cr); +#undef radius +#undef y +#undef x +#undef height +#undef width + } +#undef radius + cairo_set_line_width (cr, canvas_stroke_width); + if (NILP (hollow)) + cairo_fill (cr); + else + cairo_stroke (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); + return Qnil; +#else + error ("Not implemented"); +#endif +} + +DEFUN ("canvas-draw-string", Fcanvas_draw_string, Scanvas_draw_string, 4, 8, 0, + doc: /* Draw the string STRING onto the canvas CANVAS at X, Y. +The opacity of the drawn text will be OPACITY, and the color of the drawn text will be COLOR. +The font-family used will be FAMILY, which can be a string or a list of +the font-family as a string, whether or not the the text should be italic, +and whether or not the text should be bold. +The size of the text will be SIZE, or the default text size if nil. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object string, + Lisp_Object color, Lisp_Object opacity, Lisp_Object family, Lisp_Object size) +{ + if (noninteractive) + error ("`canvas-draw-string' cannot be called when running in batch mode."); + if (NILP (opacity)) + opacity = make_float (1.0); + if (NILP (size)) + size = make_fixnum (FRAME_TEXT_HEIGHT (XFRAME (selected_frame))); + if (NILP (family)) + family = build_string ("monospace"); + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (opacity); + if (!Flistp (family)) + CHECK_STRING (family); + CHECK_STRING (string); +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame))->query_colors + (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + struct canvas *c = XCANVAS (canvas); + cairo_t *cr = cairo_create (c->canvas); + cairo_font_slant_t slant_flags = CAIRO_FONT_SLANT_NORMAL; + cairo_font_weight_t weight_flags = CAIRO_FONT_WEIGHT_NORMAL; + const char *family_utf8; + if (!NILP (Flistp (family))) + { + if (!NILP (CALLN (Flss, Flength (family), make_fixnum (2)))) + error ("Invalid font spec"); + else + { + int length = XFIXNUM (Flength (family)); + if (length > 3) + error ("Invalid font spec"); + Lisp_Object italic, bold; + CHECK_STRING_CAR (family); + family_utf8 = SSDATA (ENCODE_UTF_8 (XCAR (family))); + if (length == 3) + bold = XCAR (XCDR (XCDR (family))); + else + bold = Qnil; + italic = XCAR (XCDR (family)); + if (!NILP (italic)) + slant_flags = CAIRO_FONT_SLANT_ITALIC; + if (!NILP (bold)) + weight_flags = CAIRO_FONT_WEIGHT_BOLD; + } + } + else + { + family_utf8 = SSDATA (ENCODE_UTF_8 (family)); + } + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_select_font_face (cr, family_utf8, + slant_flags, + weight_flags); + cairo_set_font_size (cr, XFIXNUM (size)); + cairo_move_to (cr, XFIXNUM (x), XFIXNUM (y) + XFIXNUM (size)); + cairo_show_text (cr, SSDATA (ENCODE_UTF_8 (string))); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (c); + return Qnil; +#else + return Qnil; +#endif +} + +DEFUN ("canvas-measure-string", Fcanvas_measure_string, Scanvas_measure_string, 2, 4, 0, + doc: /* Return a pair containing the width and height of STRING, +if drawn on CANVAS with the family FAMILY at SIZE. */) +(Lisp_Object canvas, Lisp_Object string, Lisp_Object family, Lisp_Object size) +{ + if (noninteractive) + error ("`canvas-draw-string' cannot be called when running in batch mode."); + if (NILP (size)) + size = make_fixnum (FRAME_TEXT_HEIGHT (XFRAME (selected_frame))); + if (NILP (family)) + family = build_string ("cairo:monospace"); + CHECK_CANVAS (canvas); + + if (!Flistp (family)) + CHECK_STRING (family); + CHECK_STRING (string); +#ifdef USE_CAIRO + struct canvas *c = XCANVAS (canvas); + cairo_t *cr = cairo_create (c->canvas); + cairo_font_slant_t slant_flags = CAIRO_FONT_SLANT_NORMAL; + cairo_font_weight_t weight_flags = CAIRO_FONT_WEIGHT_NORMAL; + const char *family_utf8; + if (!NILP (Flistp (family))) + { + if (!NILP (CALLN (Flss, Flength (family), make_fixnum (2)))) + error ("Invalid font spec"); + else + { + int length = XFIXNUM (Flength (family)); + if (length > 3) + error ("Invalid font spec"); + Lisp_Object italic, bold; + CHECK_STRING_CAR (family); + family_utf8 = SSDATA (ENCODE_UTF_8 (XCAR (family))); + if (length == 3) + bold = XCAR (XCDR (XCDR (family))); + else + bold = Qnil; + italic = XCAR (XCDR (family)); + if (!NILP (italic)) + slant_flags = CAIRO_FONT_SLANT_ITALIC; + if (!NILP (bold)) + weight_flags = CAIRO_FONT_WEIGHT_BOLD; + } + } + else + { + family_utf8 = SSDATA (ENCODE_UTF_8 (family)); + } + cairo_select_font_face (cr, family_utf8, + slant_flags, + weight_flags); + cairo_set_font_size (cr, XFIXNUM (size)); + cairo_text_extents_t extents; + cairo_text_extents (cr, SSDATA (ENCODE_UTF_8 (string)), &extents); + cairo_destroy (cr); + return Fcons (make_fixnum (extents.width), + make_fixnum (extents.height)); +#else + return Qnil; +#endif +} + +DEFUN ("canvas-draw-image", Fcanvas_draw_image, Scanvas_draw_image, 4, 8, + 0, doc: /* Paint IMAGE_SPEC onto CANVAS, at X, Y. +If WIDTH or HEIGHT is set, and IMAGE is wider than WIDTH or taller than HEIGHT, +IMAGE_SPEC will be cropped to fit WIDTH and/or HEIGHT respectively. +FRAME should be a live frame. +The opacity of the drawn image will be OPACITY. */) + (Lisp_Object canvas, Lisp_Object image_spec, + Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, + Lisp_Object frame, Lisp_Object opacity) +{ + if (valid_image_p (image_spec)) + { + if (NILP (frame)) + frame = selected_frame; + struct frame *f = decode_window_system_frame (frame); + ptrdiff_t id = lookup_image (f, image_spec); + struct image *img = IMAGE_FROM_ID (f, id); + if (!img) + return Qnil; + if (img->load_failed_p) + return Qnil; + int iwidth = img->width + 2 * img->hmargin; + int iheight = img->height + 2 * img->vmargin; + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + check_integer_range (width, 0, INT_MAX); + if (NILP (height)) + height = make_fixnum (iheight); + check_integer_range (height, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + if (NILP (opacity)) + opacity = make_fixnum (1); + CHECK_NUMBER (opacity); +#ifdef USE_CAIRO + cairo_surface_t *crs + = cairo_image_surface_create_for_data ((unsigned char *) + img->pixmap->data, + (img->pixmap->bits_per_pixel + == 32 + ? CAIRO_FORMAT_RGB24 + : CAIRO_FORMAT_A8), + img->pixmap->width, + img->pixmap->height, + img->pixmap->bytes_per_line); + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_save (cr); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_rectangle (cr, 0, 0, + XFIXNUM (width), XFIXNUM (height)); + cairo_clip (cr); + cairo_set_source_surface (cr, crs, 0, 0); + cairo_paint_with_alpha (cr, XFLOATINT (opacity)); + cairo_restore (cr); + cairo_destroy (cr); + cairo_surface_destroy (crs); + MARK_CANVAS_CHANGED (cv); +#endif + } + else + error ("Invalid image specification"); + return Qnil; +} + +DEFUN ("canvas-arc", Fcanvas_arc, Scanvas_arc, 6, 8, 0, + doc: /* Draw an arc on CANVAS starting from XC, YC, +with a radius of RADIUS and 2 angles angle1 and angle2. +Use the color COLOR with the alpha channel set to OPACITY, if specified. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object radius, + Lisp_Object angle1, Lisp_Object angle2, Lisp_Object color, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (angle1); + CHECK_NUMBER (angle2); + CHECK_NUMBER (radius); + + if (NILP (opacity)) + opacity = make_fixnum (1.0); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame)) + ->query_colors (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + cairo_t *cr = cairo_create (XCANVAS (canvas)->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_arc (cr, XFLOATINT (x), XFLOATINT (y), XFLOATINT (radius), + XFLOATINT (angle1), XFLOATINT (angle2)); + cairo_stroke (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (XCANVAS (canvas)); +#else +#endif + return Qnil; +} + +DEFUN ("canvas-filled-arc", Fcanvas_filled_arc, Scanvas_filled_arc, 6, 8, 0, + doc: /* Draw a filled arc on CANVAS starting from XC, YC, +with a radius of RADIUS and 2 angles angle1 and angle2. +Use the color COLOR with the alpha channel set to OPACITY, if specified. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y, Lisp_Object radius, + Lisp_Object angle1, Lisp_Object angle2, Lisp_Object color, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + CHECK_NUMBER (angle1); + CHECK_NUMBER (angle2); + CHECK_NUMBER (radius); + + if (NILP (opacity)) + opacity = make_fixnum (1.0); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + if (NILP (color)) + color = Qunspecified; + Lisp_Object color_values = call1 (Qcolor_values, color); + if (!NILP (color_values)) + CHECK_LIST (color_values); + double r, g, b; + if (NILP (color_values)) + { + Emacs_Color col; + col.pixel = FRAME_FOREGROUND_PIXEL (XFRAME (selected_frame)); + FRAME_TERMINAL (XFRAME (selected_frame)) + ->query_colors (XFRAME (selected_frame), &col, 1); + r = col.red / 65535.0; + g = col.green / 65535.0; + b = col.blue / 65535.0; + } + else + { + Lisp_Object lr = Fnth (make_fixnum (0), color_values), + lg = Fnth (make_fixnum (1), color_values), + lb = Fnth (make_fixnum (2), color_values); + + check_integer_range (lr, 0, 65535); + check_integer_range (lg, 0, 65535); + check_integer_range (lb, 0, 65535); + + r = XFIXNUM (lr) / 65535.0; + g = XFIXNUM (lg) / 65535.0; + b = XFIXNUM (lb) / 65535.0; + } + cairo_t *cr = cairo_create (XCANVAS (canvas)->canvas); + cairo_set_source_rgba (cr, r, g, b, XFLOATINT (opacity)); + cairo_arc (cr, XFLOATINT (x), XFLOATINT (y), XFLOATINT (radius), + XFLOATINT (angle1), XFLOATINT (angle2)); + cairo_fill (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (XCANVAS (canvas)); +#else +#endif + return Qnil; +} + +DEFUN ("canvas-region", Fcanvas_region, Scanvas_region, 5, 5, 0, + doc: /* Return a canvas containing a WIDTH wide and HEIGHT tall +subsection of CANVAS at X, Y */) + (Lisp_Object canvas, Lisp_Object x, + Lisp_Object y, Lisp_Object width, Lisp_Object height) +{ + CHECK_CANVAS (canvas); + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + check_integer_range (width, 0, INT_MAX); + check_integer_range (height, 0, INT_MAX); + +#ifdef USE_CAIRO + int ix = XFIXNUM (x), + iy = XFIXNUM (y), + iw = XFIXNUM (width), + ih = XFIXNUM (height); + cairo_surface_t *s = cairo_surface_create_for_rectangle + (XCANVAS (canvas)->canvas, ix, iy, iw, ih); + Lisp_Object newcvs = make_canvas (iw, ih); + struct canvas *target = XCANVAS (newcvs); + cairo_t *t = cairo_create (target->canvas); + cairo_set_source_surface (t, s, 0, 0); + cairo_paint (t); + cairo_destroy (t); + cairo_surface_destroy (s); + return newcvs; +#else + error ("Not implemented.") +#endif +} + + +DEFUN ("canvas-draw-canvas", Fcanvas_draw_canvas, Scanvas_draw_canvas, 4, 7, + 0, doc: /* Paint CANVAS2 onto CANVAS, at X, Y. +If WIDTH or HEIGHT is set, and IMAGE is wider than WIDTH or taller than HEIGHT, +IMAGE_SPEC will be cropped to fit WIDTH and/or HEIGHT respectively. +The opacity of the drawn image will be OPACITY. */) + (Lisp_Object canvas, Lisp_Object canvas2, + Lisp_Object x, Lisp_Object y, + Lisp_Object width, Lisp_Object height, Lisp_Object opacity) +{ + CHECK_CANVAS (canvas); + CHECK_CANVAS (canvas2); + int iwidth = XCANVAS (canvas2)->width; + int iheight = XCANVAS (canvas2)->height; + check_integer_range (x, 0, INT_MAX); + check_integer_range (y, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + check_integer_range (width, 0, INT_MAX); + if (NILP (height)) + height = make_fixnum (iheight); + check_integer_range (height, 0, INT_MAX); + if (NILP (width)) + width = make_fixnum (iwidth); + if (NILP (opacity)) + opacity = make_fixnum (1); + CHECK_NUMBER (opacity); + +#ifdef USE_CAIRO + cairo_surface_t *crs = XCANVAS (canvas2)->canvas; + struct canvas *cv = XCANVAS (canvas); + cairo_t *cr = cairo_create (cv->canvas); + cairo_save (cr); + cairo_translate (cr, XFIXNUM (x), XFIXNUM (y)); + cairo_rectangle (cr, 0, 0, XFIXNUM (width), XFIXNUM (height)); + cairo_clip (cr); + cairo_set_source_surface (cr, crs, 0, 0); + cairo_paint_with_alpha (cr, XFLOATINT (opacity)); + cairo_restore (cr); + cairo_destroy (cr); + MARK_CANVAS_CHANGED (cv); +#endif + return Qnil; +} + +DEFUN ("canvas-pixel-at", Fcanvas_pixel_at, Scanvas_pixel_at, 3, 3, 0, + doc: /* Return the color of the pixel at X, Y inside CANVAS as an ARGB list. */) + (Lisp_Object canvas, Lisp_Object x, Lisp_Object y) +{ +#ifndef USE_CAIRO + error ("Not implemented."); +#else + CHECK_CANVAS (canvas); + check_integer_range (x, 0, XCANVAS (canvas)->width); + check_integer_range (y, 0, XCANVAS (canvas)->height); + struct { +#ifdef WORDS_BIGENDIAN + uint8_t a, r, g, b; +#else + uint8_t b, g, r, a; +#endif + } *argb32 = + (void *) cairo_image_surface_get_data (XCANVAS (canvas)->canvas); + typeof (*argb32) res = argb32 [XFIXNUM (y) * XCANVAS (canvas)->width + + XFIXNUM (x)]; + return CALLN (Flist, make_fixnum (res.a), + make_fixnum (res.r), + make_fixnum (res.g), + make_fixnum (res.b)); +#endif +} + +DEFUN ("canvas-dimensions", Fcanvas_dimensions, Scanvas_dimensions, 1, 1, 0, + doc: /* Return a cons pair containing the width and height of CANVAS. */) + (Lisp_Object canvas) +{ + CHECK_CANVAS (canvas); + return Fcons (make_fixnum (XCANVAS (canvas)->width), + make_fixnum (XCANVAS (canvas)->height)); +} + +void +syms_of_canvas (void) +{ + defsubr (&Smake_canvas); + defsubr (&Scanvas_rectangle); + defsubr (&Scanvas_ellipse); + defsubr (&Scanvas_rectangle); + defsubr (&Scanvas_draw_string); + defsubr (&Scanvas_draw_image); + defsubr (&Scanvas_draw_canvas); + defsubr (&Scanvas_measure_string); + defsubr (&Scanvas_dimensions); + defsubr (&Scanvas_region); + defsubr (&Scanvas_pixel_at); + defsubr (&Scanvas_arc); + defsubr (&Scanvasp); + defsubr (&Scanvas_filled_arc); + defsubr (&Scanvas_rounded_rectangle); + DEFSYM (Qcanvas_rounded_rectangle, "canvas-rounded-rectangle"); + DEFSYM (Qcanvasp, "canvasp"); + DEFSYM (Qcolor_values, "color-values"); + DEFVAR_INT ("canvas-stroke-width", canvas_stroke_width, + doc: /* The stroke width to be used in canvases. */); + canvas_stroke_width = 4; +} diff --git a/src/data.c b/src/data.c index bce2e53cfb..aefd6d7e70 100644 --- a/src/data.c +++ b/src/data.c @@ -263,6 +263,8 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, return Qxwidget; case PVEC_XWIDGET_VIEW: return Qxwidget_view; + case PVEC_CANVAS: + return Qcanvas; /* "Impossible" cases. */ case PVEC_MISC_PTR: case PVEC_OTHER: @@ -3859,6 +3861,7 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qchar_table, "char-table"); DEFSYM (Qbool_vector, "bool-vector"); DEFSYM (Qhash_table, "hash-table"); + DEFSYM (Qcanvas, "canvas"); DEFSYM (Qthread, "thread"); DEFSYM (Qmutex, "mutex"); DEFSYM (Qcondition_variable, "condition-variable"); diff --git a/src/dispextern.h b/src/dispextern.h index 0b1f3d14ae..d33b87c3df 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -382,7 +382,10 @@ #define SET_GLYPH_FROM_GLYPH_CODE(glyph, gc) \ STRETCH_GLYPH, /* Glyph is an external widget drawn by the GUI toolkit. */ - XWIDGET_GLYPH + XWIDGET_GLYPH, + + /* Glyph is a canvas. */ + CANVAS_GLYPH }; @@ -540,6 +543,9 @@ #define FACE_ID_BITS 20 struct xwidget *xwidget; #endif + /* Canvas reference (type == CANVAS_GLYPH). */ + struct canvas *canvas; + /* Sub-structure for type == STRETCH_GLYPH. */ struct { @@ -1405,6 +1411,9 @@ #define OVERLAPS_ERASED_CURSOR (1 << 2) /* Xwidget. */ struct xwidget *xwidget; + /* Canvas. */ + struct canvas *canvas; + /* Slice */ struct glyph_slice slice; @@ -2158,7 +2167,10 @@ #define MAX_FRINGE_BITMAPS (1<<FRINGE_ID_BITS) IT_CONTINUATION, /* Xwidget. */ - IT_XWIDGET + IT_XWIDGET, + + /* Canvas. */ + IT_CANVAS }; @@ -2223,6 +2235,7 @@ #define MAX_FRINGE_BITMAPS (1<<FRINGE_ID_BITS) GET_FROM_IMAGE, GET_FROM_STRETCH, GET_FROM_XWIDGET, + GET_FROM_CANVAS, NUM_IT_METHODS }; @@ -2447,6 +2460,10 @@ #define OVERLAY_STRING_CHUNK_SIZE 16 struct { Lisp_Object object; } xwidget; + /* method == GET_FROM_CANVAS */ + struct { + Lisp_Object object; + } canvas; } u; /* Current text and display positions. */ @@ -2578,6 +2595,9 @@ #define OVERLAY_STRING_CHUNK_SIZE 16 /* If what == IT_XWIDGET. */ struct xwidget *xwidget; + /* If what == IT_CANVAS. */ + struct canvas *canvas; + /* Values from `slice' property. */ struct it_slice slice; @@ -3714,6 +3734,11 @@ #define IMAGE_BACKGROUND_TRANSPARENT(img, f, mask) \ #endif /* HAVE_WINDOW_SYSTEM */ +extern void +canvas_update_glyph (struct window *w, int x, struct glyph_row *row, + enum glyph_row_area area, ptrdiff_t start, ptrdiff_t end, + struct glyph *glyph); + INLINE_HEADER_END #endif /* not DISPEXTERN_H_INCLUDED */ diff --git a/src/dispnew.c b/src/dispnew.c index 5b6fa51a56..9e0c1a060e 100644 --- a/src/dispnew.c +++ b/src/dispnew.c @@ -43,6 +43,7 @@ Copyright (C) 1985-1988, 1993-1995, 1997-2020 Free Software Foundation, #include "tparam.h" #include "xwidget.h" #include "pdumper.h" +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER @@ -3697,6 +3698,7 @@ update_window (struct window *w, bool force_p) #endif xwidget_end_redisplay (w, w->current_matrix); + canvas_end_redisplay (w, w->current_matrix); clear_glyph_matrix (desired_matrix); return paused_p; @@ -3782,6 +3784,7 @@ gui_update_window_end (struct window *w, bool cursor_on_p, FRAME_RIF (f)->update_window_end_hook (w, cursor_on_p, mouse_face_overwritten_p); + canvas_end_redisplay (w, w->current_matrix); } #endif /* HAVE_WINDOW_SYSTEM */ @@ -4371,6 +4374,11 @@ scrolling_window (struct window *w, int tab_line_p) return 0; #endif + /* We need this to fix canvas movement detection in a reliable way. + FIXME. */ + if (w->have_canvas_p) + return 0; + /* Give up if some rows in the desired matrix are not enabled. */ if (! MATRIX_ROW_ENABLED_P (desired_matrix, i)) return -1; @@ -5462,6 +5470,10 @@ buffer_posn_from_coords (struct window *w, int *x, int *y, struct display_pos *p if (img && !NILP (img->spec)) *object = img->spec; } + else if (it.what == IT_CANVAS) + { + XSETCANVAS (*object, it.canvas); + } #endif /* IT's vpos counts from the glyph row that includes the window's @@ -5565,6 +5577,10 @@ mode_line_string (struct window *w, enum window_part part, y0 -= row->ascent - glyph->ascent; } #endif + if (glyph->type == CANVAS_GLYPH) + { + y0 -= row->ascent - glyph->ascent; + } } else { @@ -5654,6 +5670,10 @@ marginal_area_string (struct window *w, enum window_part part, y0 += glyph->slice.img.y; } #endif + if (glyph->type == CANVAS_GLYPH) + { + y0 -= row->ascent - glyph->ascent; + } } else { diff --git a/src/emacs.c b/src/emacs.c index ea9c4cd79d..c16af2c14c 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -94,6 +94,8 @@ #define MAIN_PROGRAM #include "getpagesize.h" #include "gnutls.h" +#include "canvas.h" + #ifdef PROFILING # include <sys/gmon.h> extern void moncontrol (int mode); @@ -1567,6 +1569,8 @@ main (int argc, char **argv) /* Before init_window_once, because it sets up the Vcoding_system_hash_table. */ syms_of_coding (); /* This should be after syms_of_fileio. */ + + syms_of_canvas (); init_frame_once (); /* Before init_window_once. */ init_window_once (); /* Init the window system. */ #ifdef HAVE_WINDOW_SYSTEM diff --git a/src/lisp.h b/src/lisp.h index b4ac017dcf..f463399dad 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1103,6 +1103,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) PVEC_MUTEX, PVEC_CONDVAR, PVEC_MODULE_FUNCTION, + PVEC_CANVAS, /* These should be last, for internal_equal and sxhash_obj. */ PVEC_COMPILED, @@ -1349,6 +1350,7 @@ #define XSETSUB_CHAR_TABLE(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_SUB_CHAR_TABLE)) #define XSETTHREAD(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_THREAD)) #define XSETMUTEX(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_MUTEX)) #define XSETCONDVAR(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_CONDVAR)) +#define XSETCANVAS(a, b) (XSETPSEUDOVECTOR (a, b, PVEC_CANVAS)) /* Efficiently convert a pointer to a Lisp object and back. The pointer is represented as a fixnum, so the garbage collector diff --git a/src/pdumper.c b/src/pdumper.c index 63424c5734..33c527c7d8 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -3036,6 +3036,8 @@ dump_vectorlike (struct dump_context *ctx, error_unsupported_dump_object (ctx, lv, "condvar"); case PVEC_MODULE_FUNCTION: error_unsupported_dump_object (ctx, lv, "module function"); + case PVEC_CANVAS: + error_unsupported_dump_object (ctx, lv, "canvas"); default: error_unsupported_dump_object(ctx, lv, "weird pseudovector"); } diff --git a/src/print.c b/src/print.c index bd1769144e..28a620fd20 100644 --- a/src/print.c +++ b/src/print.c @@ -34,6 +34,7 @@ Copyright (C) 1985-1986, 1988, 1993-1995, 1997-2020 Free Software #include "blockinput.h" #include "xwidget.h" #include "dynlib.h" +#include "canvas.h" #include <c-ctype.h> #include <float.h> @@ -1833,6 +1834,16 @@ print_vectorlike (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag, } break; #endif + case PVEC_CANVAS: + { + print_c_string ("#<canvas ", printcharfun); + const struct canvas *canvas = XCANVAS (obj); + print_object (make_fixnum (canvas->width), printcharfun, false); + printchar ('x', printcharfun); + print_object (make_fixnum (canvas->height), printcharfun, false); + print_c_string (">", printcharfun); + } + break; default: emacs_abort (); diff --git a/src/window.c b/src/window.c index e2dea8b70e..5e0ed1ab94 100644 --- a/src/window.c +++ b/src/window.c @@ -4289,6 +4289,7 @@ make_window (void) w->scroll_bar_width = -1; w->scroll_bar_height = -1; w->column_number_displayed = -1; + w->have_canvas_p = false; /* Reset window_list. */ Vwindow_list = Qnil; /* Return window. */ diff --git a/src/window.h b/src/window.h index 167d1be7ab..67c7417007 100644 --- a/src/window.h +++ b/src/window.h @@ -445,6 +445,9 @@ #define WINDOW_H_INCLUDED window. */ bool_bf suspend_auto_hscroll : 1; + /* True if we think a canvas is being displayed in this window. */ + bool_bf have_canvas_p : 1; + /* Amount by which lines of this window are scrolled in y-direction (smooth scrolling). */ int vscroll; diff --git a/src/xdisp.c b/src/xdisp.c index 140d134572..758f07fec5 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -462,6 +462,7 @@ Copyright (C) 1985-1988, 1993-1995, 1997-2020 Free Software Foundation, #include "fontset.h" #include "blockinput.h" #include "xwidget.h" +#include "canvas.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ @@ -1055,6 +1056,7 @@ #define THIN_SPACE_WIDTH 1 static bool next_element_from_image (struct it *); static bool next_element_from_stretch (struct it *); static bool next_element_from_xwidget (struct it *); +static bool next_element_from_canvas (struct it *); static void load_overlay_strings (struct it *, ptrdiff_t); static bool get_next_display_element (struct it *); static enum move_it_result @@ -2688,7 +2690,7 @@ remember_mouse_glyph (struct frame *f, int gx, int gy, NativeRectangle *rect) if (g < end) { - if (g->type == IMAGE_GLYPH) + if (g->type == IMAGE_GLYPH || g->type == CANVAS_GLYPH) { /* Don't remember when mouse is over image, as image may have hot-spots. */ @@ -5589,7 +5591,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, /* After this point, VALUE is the property after any margin prefix has been stripped. It must be a string, - an image specification, or `(space ...)'. + an image specification, a canvas, or `(space ...)'. LOCATION specifies where to display: `left-margin', `right-margin' or nil. */ @@ -5601,7 +5603,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, #endif /* not HAVE_WINDOW_SYSTEM */ || (CONSP (value) && EQ (XCAR (value), Qspace)) || ((it ? FRAME_WINDOW_P (it->f) : frame_window_p) - && valid_xwidget_spec_p (value))); + && valid_xwidget_spec_p (value))) || CANVASP (value); if (valid_p && display_replaced == 0) { @@ -5686,6 +5688,22 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, *position = start_pos; it->xwidget = lookup_xwidget (value); } + else if (CANVASP (value)) + { + it->what = IT_CANVAS; + it->method = GET_FROM_CANVAS; + it->position = start_pos; + it->object = NILP (object) ? it->w->contents : object; + *position = start_pos; + it->canvas = XCANVAS (value); + if ((!NILP (it->canvas->object) && + !EQ (it->canvas->object, it->object)) || + (!NILP (it->canvas->window) && + XWINDOW (it->canvas->window) != it->w)) + it->canvas->multiple_objects_seen = true; + it->canvas->object = it->object; + XSETWINDOW (it->canvas->window, it->w); + } #ifdef HAVE_WINDOW_SYSTEM else { @@ -6446,6 +6464,9 @@ push_it (struct it *it, struct text_pos *position) case GET_FROM_XWIDGET: p->u.xwidget.object = it->object; break; + case GET_FROM_CANVAS: + p->u.canvas.object = it->object; + break; case GET_FROM_BUFFER: case GET_FROM_DISPLAY_VECTOR: case GET_FROM_STRING: @@ -6550,6 +6571,9 @@ pop_it (struct it *it) case GET_FROM_XWIDGET: it->object = p->u.xwidget.object; break; + case GET_FROM_CANVAS: + it->object = p->u.canvas.object; + break; case GET_FROM_STRETCH: it->object = p->u.stretch.object; break; @@ -7236,6 +7260,7 @@ reseat_to_string (struct it *it, const char *s, Lisp_Object string, next_element_from_image, next_element_from_stretch, next_element_from_xwidget, + next_element_from_canvas, }; #define GET_NEXT_DISPLAY_ELEMENT(it) (*get_next_element[(it)->method]) (it) @@ -8151,6 +8176,7 @@ set_iterator_to_next (struct it *it, bool reseat_p) case GET_FROM_IMAGE: case GET_FROM_STRETCH: case GET_FROM_XWIDGET: + case GET_FROM_CANVAS: /* The position etc with which we have to proceed are on the stack. The position may be at the end of a string, @@ -8619,6 +8645,12 @@ next_element_from_xwidget (struct it *it) return true; } +static bool +next_element_from_canvas (struct it *it) +{ + it->what = IT_CANVAS; + return true; +} /* Fill iterator IT with next display element from a stretch glyph property. IT->object is the value of the text property. Value is @@ -27810,6 +27842,19 @@ fill_xwidget_glyph_string (struct glyph_string *s) s->xwidget = s->first_glyph->u.xwidget; } #endif + +static void +fill_canvas_glyph_string (struct glyph_string *s) +{ + eassert (s->first_glyph->type == CANVAS_GLYPH); + s->w->have_canvas_p = true; + s->face = FACE_FROM_ID (s->f, s->first_glyph->face_id); + s->font = s->face->font; + s->width = s->first_glyph->pixel_width; + s->ybase += s->first_glyph->voffset; + s->canvas = s->first_glyph->u.canvas; + s->canvas->changed_since_last_redisplay = false; +} /* Fill glyph string S from a sequence of stretch glyphs. START is the index of the first glyph to consider, @@ -28227,6 +28272,18 @@ #define BUILD_IMAGE_GLYPH_STRING(START, END, HEAD, TAIL, HL, X, LAST_X) \ while (false) #endif +#define BUILD_CANVAS_GLYPH_STRING(START, END, HEAD, TAIL, HL, X, LAST_X) \ + do \ + { \ + s = alloca (sizeof *s); \ + INIT_GLYPH_STRING (s, NULL, w, row, area, START, HL); \ + append_glyph_string (&(HEAD), &(TAIL), s); \ + ++(START); \ + s->x = (X); \ + fill_canvas_glyph_string (s); \ + } \ + while (false) + /* Add a glyph string for a sequence of character glyphs to the list of strings between HEAD and TAIL. START is the index of the first glyph in row area AREA of glyph row ROW that is part of the new @@ -28378,7 +28435,11 @@ #define BUILD_GLYPH_STRINGS_1(START, END, HEAD, TAIL, HL, X, LAST_X) \ case IMAGE_GLYPH: \ BUILD_IMAGE_GLYPH_STRING (START, END, HEAD, TAIL, \ HL, X, LAST_X); \ - break; + break; \ + case CANVAS_GLYPH: \ + BUILD_CANVAS_GLYPH_STRING (START, END, HEAD, TAIL, \ + HL, X, LAST_X); \ + break; \ #define BUILD_GLYPH_STRINGS_XW(START, END, HEAD, TAIL, HL, X, LAST_X) \ case XWIDGET_GLYPH: \ @@ -29086,6 +29147,116 @@ produce_image_glyph (struct it *it) } } +static void +produce_canvas_glyph (struct it *it) +{ + struct canvas *canvas; + int glyph_ascent, crop; + + eassert (it->what == IT_CANVAS); + + struct face *face = FACE_FROM_ID (it->f, it->face_id); + prepare_face_for_display (it->f, face); + + canvas = it->canvas; + it->ascent = it->phys_ascent = glyph_ascent = canvas->height / 2; + it->descent = it->phys_descent = canvas->height / 2; + it->pixel_width = canvas->width; + + if (it->descent < 0) + it->descent = 0; + + it->nglyphs = 1; + + if (face->box != FACE_NO_BOX) + { + if (face->box_horizontal_line_width > 0) + { + it->ascent += face->box_horizontal_line_width; + it->descent += face->box_horizontal_line_width; + } + + if (face->box_vertical_line_width > 0) + { + if (it->start_of_box_run_p) + it->pixel_width += face->box_vertical_line_width; + it->pixel_width += face->box_vertical_line_width; + } + } + + take_vertical_position_into_account (it); + + /* Automatically crop wide canvas glyphs at right edge so we can + draw the cursor on same display row. */ + crop = it->pixel_width - (it->last_visible_x - it->current_x); + if (crop > 0 && (it->hpos == 0 || it->pixel_width > it->last_visible_x / 4)) + it->pixel_width -= crop; + + if (it->glyph_row) + { + enum glyph_row_area area = it->area; + struct glyph *glyph + = it->glyph_row->glyphs[area] + it->glyph_row->used[area]; + + if (it->glyph_row->reversed_p) + { + struct glyph *g; + + /* Make room for the new glyph. */ + for (g = glyph - 1; g >= it->glyph_row->glyphs[it->area]; g--) + g[1] = *g; + glyph = it->glyph_row->glyphs[it->area]; + } + if (glyph < it->glyph_row->glyphs[area + 1]) + { + glyph->charpos = CHARPOS (it->position); + glyph->object = it->object; + glyph->pixel_width = clip_to_bounds (-1, it->pixel_width, SHRT_MAX); + glyph->ascent = glyph_ascent; + glyph->descent = it->descent; + glyph->voffset = it->voffset; + glyph->type = CANVAS_GLYPH; + glyph->avoid_cursor_p = it->avoid_cursor_p; + glyph->multibyte_p = it->multibyte_p; + glyph->u.canvas = it->canvas; + if (it->glyph_row->reversed_p && area == TEXT_AREA) + { + /* In R2L rows, the left and the right box edges need to be + drawn in reverse direction. */ + glyph->right_box_line_p = it->start_of_box_run_p; + glyph->left_box_line_p = it->end_of_box_run_p; + } + else + { + glyph->left_box_line_p = it->start_of_box_run_p; + glyph->right_box_line_p = it->end_of_box_run_p; + } + glyph->overlaps_vertically_p = 0; + glyph->padding_p = 0; + glyph->glyph_not_available_p = 0; + glyph->face_id = it->face_id; + glyph->font_type = FONT_TYPE_UNKNOWN; + if (it->bidi_p) + { + glyph->resolved_level = it->bidi_it.resolved_level; + eassert ((it->bidi_it.type & 7) == it->bidi_it.type); + glyph->bidi_type = it->bidi_it.type; + } + ++it->glyph_row->used[area]; + } + else + IT_EXPAND_MATRIX_WIDTH (it, area); + } +} + +void +canvas_update_glyph (struct window *w, int x, struct glyph_row *row, + enum glyph_row_area area, ptrdiff_t start, ptrdiff_t end, + struct glyph *glyph) +{ + draw_glyphs (w, x, row, area, start, end, DRAW_NORMAL_TEXT, 0); +} + static void produce_xwidget_glyph (struct it *it) { @@ -30608,6 +30779,8 @@ gui_produce_glyphs (struct it *it) produce_stretch_glyph (it); else if (it->what == IT_XWIDGET) produce_xwidget_glyph (it); + else if (it->what == IT_CANVAS) + produce_canvas_glyph (it); done: /* Accumulate dimensions. Note: can't assume that it->descent > 0 @@ -31008,6 +31181,10 @@ get_window_cursor_type (struct window *w, struct glyph *glyph, int *width, cursor_type = HOLLOW_BOX_CURSOR; } } + if (glyph != NULL && glyph->type == CANVAS_GLYPH) + { + cursor_type = HOLLOW_BOX_CURSOR; + } return cursor_type; } diff --git a/src/xterm.c b/src/xterm.c index 7989cecec7..716ed0ef97 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -75,6 +75,7 @@ Copyright (C) 1989, 1993-2020 Free Software Foundation, Inc. #include "sysselect.h" #include "menu.h" #include "pdumper.h" +#include "canvas.h" #ifdef USE_X_TOOLKIT #include <X11/Shell.h> @@ -2066,6 +2067,30 @@ x_draw_glyphless_glyph_string_foreground (struct glyph_string *s) } } +static void +x_draw_canvas_glyph_string_foreground (struct glyph_string *s) +{ + eassert (s->first_glyph->type == CANVAS_GLYPH); +#ifdef USE_CAIRO + cairo_t *cr = x_begin_cr_clip (s->f, s->gc); + int x = s->x; + int y = s->ybase - s->first_glyph->ascent; + + if (s->face->box != FACE_NO_BOX && + s->first_glyph->left_box_line_p) + x += max (s->face->box_vertical_line_width, 0); + + x_set_glyph_string_clipping (s); + x_clear_area (s->f, x, y, s->width, s->height); + cairo_set_source_surface (cr, s->canvas->canvas, + s->x, s->y); + cairo_paint (cr); + x_end_cr_clip (s->f); +#else + emacs_abort (); +#endif +} + #ifdef USE_X_TOOLKIT #ifdef USE_LUCID @@ -3811,6 +3836,11 @@ x_draw_glyph_string (struct glyph_string *s) x_draw_glyphless_glyph_string_foreground (s); break; + case CANVAS_GLYPH: + x_draw_glyph_string_background (s, true); + x_draw_canvas_glyph_string_foreground (s); + break; + default: emacs_abort (); } ^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:27 ` Po Lu via Emacs development discussions. @ 2020-04-29 11:47 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 11:47 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 18:27:49 +0800 > > >> That's the technical description of the implementation. It doesn't > >> explain when canvases can be useful and for what purposes. > > > > Canvases are useful for when I want to be able to control a portion of a > > screen dynamically, in a fast way, from Lisp code. For instance, > > displaying a constantly changing bar chart or graph inside Emacs. > > > >> But the result of this painting is some graphical object, similar to > >> an image, that will be displayed within a buffer, right? > > > > Correct. > > > >> Did I miss the code that tells Emacs the click was on a canvas? E.g., > >> if you click on a canvas, what does posn-object return when passed the > >> click event as its argument? > > > > Oops. I missed that. Thanks for bringing it up. > > Here is a version of the patch with several of the problems you > mentioned rectified. Thanks. > +@node Canvases > +@cindex drawing canvases > +@cindex drawing areas > +@cindex canvases > +@section Canvases > + > +This chapter describes canvases, objects that can store drawing operations > +which are then displayed inside buffer text. Please consider telling something here about when this is useful. Also, I think there should be a short subsection in "Editing Types" with the description of the canvas type, like we have for other editing types. > @@ -4371,6 +4374,11 @@ scrolling_window (struct window *w, int tab_line_p) > return 0; > #endif > > + /* We need this to fix canvas movement detection in a reliable way. > + FIXME. */ > + if (w->have_canvas_p) > + return 0; This is sub-optimal. Please don't follow the xwidget example of disabling redisplay optimizations because it might be hairy to support them. It would make any window with canvases redisplay much slower in many cases. > @@ -5462,6 +5470,10 @@ buffer_posn_from_coords (struct window *w, int *x, int *y, struct display_pos *p > if (img && !NILP (img->spec)) > *object = img->spec; > } > + else if (it.what == IT_CANVAS) > + { > + XSETCANVAS (*object, it.canvas); > + } > #endif This is just the object. That's okay, but don't you want to support clicks on various parts of the canvas, like we do with images? That would require more info to be returned. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:22 ` Po Lu 2020-04-29 10:27 ` Po Lu via Emacs development discussions. @ 2020-04-29 10:35 ` Eli Zaretskii 2020-04-29 10:41 ` Po Lu 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 10:35 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 18:22:13 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > That's the technical description of the implementation. It doesn't > > explain when canvases can be useful and for what purposes. > > Canvases are useful for when I want to be able to control a portion of a > screen dynamically, in a fast way, from Lisp code. For instance, > displaying a constantly changing bar chart or graph inside Emacs. So this _is_ a way of putting images on the Emacs display, but in a way that creates the image dynamically from Lisp, instead of reading it from a file or producing the binary data for that image. Right? Incidentally, how does this compare with functions in svg.el? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:35 ` Eli Zaretskii @ 2020-04-29 10:41 ` Po Lu 2020-04-29 11:51 ` Eli Zaretskii 2020-04-29 16:14 ` David Engster 0 siblings, 2 replies; 53+ messages in thread From: Po Lu @ 2020-04-29 10:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > So this _is_ a way of putting images on the Emacs display, but in a > way that creates the image dynamically from Lisp, instead of reading > it from a file or producing the binary data for that image. Right? Yes. > Incidentally, how does this compare with functions in svg.el? While right now svg.el seems to have more features, it isn't particularly well suited to displaying things quickly. In fact, my own bad experiences with using svg.el to draw rapidly changing information inspired me to begin working on this. In the future, I hope that canvases also become more flexible than svg.el. A nice goal would be to have everything cairo has. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:41 ` Po Lu @ 2020-04-29 11:51 ` Eli Zaretskii 2020-04-29 12:12 ` Po Lu 2020-04-29 16:14 ` David Engster 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 11:51 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 18:41:08 +0800 > > > Incidentally, how does this compare with functions in svg.el? > > While right now svg.el seems to have more features, it isn't > particularly well suited to displaying things quickly. > > In fact, my own bad experiences with using svg.el to draw rapidly > changing information inspired me to begin working on this. What exactly is slow there, and why? > In the future, I hope that canvases also become more flexible than > svg.el. A nice goal would be to have everything cairo has. If canvasses are meant to be a replacement for svg.el, we need to keep both equivalent, functionality-wise, for the benefit of platforms that don't use Cairo, and also to ease the transition period for those platforms which do. So the relation between svg.el and canvasses should be rethought, I think. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 11:51 ` Eli Zaretskii @ 2020-04-29 12:12 ` Po Lu 0 siblings, 0 replies; 53+ messages in thread From: Po Lu @ 2020-04-29 12:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If canvasses are meant to be a replacement for svg.el, we need to keep > both equivalent, functionality-wise, for the benefit of platforms that > don't use Cairo, and also to ease the transition period for those > platforms which do. > > So the relation between svg.el and canvasses should be rethought, I > think. Yeah you indeed have a point there. I'll think over this tonight. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 10:41 ` Po Lu 2020-04-29 11:51 ` Eli Zaretskii @ 2020-04-29 16:14 ` David Engster 2020-04-29 16:54 ` Eli Zaretskii 2020-04-29 17:08 ` Eli Zaretskii 1 sibling, 2 replies; 53+ messages in thread From: David Engster @ 2020-04-29 16:14 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, emacs-devel > While right now svg.el seems to have more features, it isn't > particularly well suited to displaying things quickly. > > In fact, my own bad experiences with using svg.el to draw rapidly > changing information inspired me to begin working on this. > > In the future, I hope that canvases also become more flexible than > svg.el. A nice goal would be to have everything cairo has. A while ago I played around with using Cairo primitives to draw in Emacs. While it would be nice to have something like a 'canvas object' to draw on, Eli is correct that you can achieve similar things already with SVG - it may be slow, but that could be fixable. IMHO, What would be much more exciting, is if you could draw directly over normal text. This would enable a whole new set of possibilities. For instance, I always liked visual diff tools like 'Meld' or 'Code Compare', but I don't see how you could do this with Emacs. Or things like proper indentation guides, or widgets inside text for code folding. Yes, those can be done in Emacs today, but it is very difficult to get right and often not really satisfactory (weird interactions between packages, too slow, etc.). I know the tricky part is not the drawing, but redisplay. I would have no idea how to handle this. -David ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 16:14 ` David Engster @ 2020-04-29 16:54 ` Eli Zaretskii 2020-04-29 17:16 ` tomas ` (2 more replies) 2020-04-29 17:08 ` Eli Zaretskii 1 sibling, 3 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 16:54 UTC (permalink / raw) To: David Engster; +Cc: luangruo, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 18:14:55 +0200 > > IMHO, What would be much more exciting, is if you could draw directly > over normal text. This would enable a whole new set of > possibilities. For instance, I always liked visual diff tools like > 'Meld' or 'Code Compare', but I don't see how you could do this with > Emacs. Or things like proper indentation guides, or widgets inside text > for code folding. Yes, those can be done in Emacs today, but it is very > difficult to get right and often not really satisfactory (weird > interactions between packages, too slow, etc.). AFAIU, Meld seems to draw the graphics _between_ windows, and only highlights the source lines with background colors. I think we can do that if we use an extra window in-between the two being compared, and put images in that extra window to show the graphical description of the changes between the two versions. Drawing over normal text, if we don't want to redesign the entire display engine, needs some new kind of "display element" ( a sibling to "character", "image", "stretch", etc.), one that doesn't necessarily have any effect on the metrics of the screen lines it is drawn upon. I'm not sure I have a clear idea about what features such a drawing will need to support, but it could be possible to add such an element with not too much effort. Would someone want to come up with a reasonable list of requirements for such a feature? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 16:54 ` Eli Zaretskii @ 2020-04-29 17:16 ` tomas 2020-04-29 17:27 ` Eli Zaretskii 2020-04-29 19:23 ` David Engster 2020-04-30 6:52 ` Corwin Brust 2 siblings, 1 reply; 53+ messages in thread From: tomas @ 2020-04-29 17:16 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 914 bytes --] On Wed, Apr 29, 2020 at 07:54:02PM +0300, Eli Zaretskii wrote: [...] > Drawing over normal text, if we don't want to redesign the entire > display engine, needs some new kind of "display element" ( a sibling > to "character", "image", "stretch", etc.), one that doesn't > necessarily have any effect on the metrics of the screen lines it is > drawn upon. I'm not sure I have a clear idea about what features such > a drawing will need to support, but it could be possible to add such > an element with not too much effort. Would someone want to come up > with a reasonable list of requirements for such a feature? That sounds... exciting. Basically, Emacs would have to have a "display list" of graphical elements to draw, each one perhaps having a bounding box (to discard those from redisplay which aren't currently visible) and perhaps a "layer" (more to the background or foreground). Hmmm. Cheers -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 17:16 ` tomas @ 2020-04-29 17:27 ` Eli Zaretskii 2020-04-29 17:38 ` Eli Zaretskii 2020-04-29 18:51 ` tomas 0 siblings, 2 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 17:27 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 19:16:19 +0200 > From: <tomas@tuxteam.de> > > > Drawing over normal text, if we don't want to redesign the entire > > display engine, needs some new kind of "display element" ( a sibling > > to "character", "image", "stretch", etc.), one that doesn't > > necessarily have any effect on the metrics of the screen lines it is > > drawn upon. I'm not sure I have a clear idea about what features such > > a drawing will need to support, but it could be possible to add such > > an element with not too much effort. Would someone want to come up > > with a reasonable list of requirements for such a feature? > > That sounds... exciting. Basically, Emacs would have to have a "display > list" of graphical elements to draw, each one perhaps having a bounding > box (to discard those from redisplay which aren't currently visible) > and perhaps a "layer" (more to the background or foreground). That's not how Emacs controls what's on display. It basically represents each window as a 2D array of glyphs, each one of which has a certain graphical representation. The representation itself is of no concern to the display engine (well, almost); the only thing it cares about is the metrics of each glyph, because that's what it needs to do layout calculations. We need to try to fit into this framework, if possible. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 17:27 ` Eli Zaretskii @ 2020-04-29 17:38 ` Eli Zaretskii 2020-04-30 13:11 ` Arthur Miller 2020-04-29 18:51 ` tomas 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 17:38 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 20:27:53 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > That's not how Emacs controls what's on display. It basically > represents each window as a 2D array of glyphs, each one of which has > a certain graphical representation. The representation itself is of > no concern to the display engine (well, almost); the only thing it > cares about is the metrics of each glyph, because that's what it needs > to do layout calculations. Oh, and one more important aspect: everything that winds up on display must come from some buffer or some Lisp string. It could be a special text property or somesuch, but it must be found by walking some buffer or some known-in-advance Lisp string, because that's what top-level display functions do: they iterate over these objects, and produce the glyphs based on what they find there. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 17:38 ` Eli Zaretskii @ 2020-04-30 13:11 ` Arthur Miller 2020-04-30 14:18 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Arthur Miller @ 2020-04-30 13:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Wed, 29 Apr 2020 20:27:53 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: emacs-devel@gnu.org >> >> That's not how Emacs controls what's on display. It basically >> represents each window as a 2D array of glyphs, each one of which has >> a certain graphical representation. The representation itself is of >> no concern to the display engine (well, almost); the only thing it >> cares about is the metrics of each glyph, because that's what it needs >> to do layout calculations. > > Oh, and one more important aspect: everything that winds up on display > must come from some buffer or some Lisp string. It could be a special > text property or somesuch, but it must be found by walking some buffer > or some known-in-advance Lisp string, because that's what top-level > display functions do: they iterate over these objects, and produce the > glyphs based on what they find there. I have a question here about display: when lisp engine decides to draw the display, how difficult would it be to add a callback for pre- and post render? Prerender callback could be any user lisp function called that do anything it wants, say draw something on the screen as it owned window itself. Than render engine would it's ordinary rendering drawing just as it does now, pretending that there was nothing already drawn, so it would mean no change at all to current c code for rendering. Similarly one call a post-render callback and draw over the already rendered text so user could draw whatever on top of already draw onverlas and what not. It is just how z-buffer works and it would mean z order from pre-render, normal render (as it is now) and post render as implicit z-depths. Finally one could expose ordinary X11, GDI, Cairo drawing funcions so thet draw to an image (or why not directly to the gui window?) that could be displayed say in prerender hook, which would get drawn as background below the buffer text, and woulnd't collide with overlays and other stuff. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 13:11 ` Arthur Miller @ 2020-04-30 14:18 ` Eli Zaretskii 2020-04-30 14:58 ` Arthur Miller 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 14:18 UTC (permalink / raw) To: Arthur Miller; +Cc: tomas, emacs-devel > From: Arthur Miller <arthur.miller@live.com> > Date: Thu, 30 Apr 2020 15:11:10 +0200 > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > > I have a question here about display: when lisp engine decides to draw > the display, how difficult would it be to add a callback for pre- and > post render? I don't think I understand the question. It is trivial to add a call to a Lisp function anywhere in Emacs, the question is what that function will be able to do to be useful. If the called Lisp can do anything it wants, then how can it be useful without knowing a whole lot about the window layout, and what was just now, or will be in a moment, drawn on it, and in which parts? > Prerender callback could be any user lisp function called > that do anything it wants, say draw something on the screen as it owned > window itself. Than render engine would it's ordinary rendering drawing > just as it does now, pretending that there was nothing already drawn, so > it would mean no change at all to current c code for rendering. So how do we prevent the display engine from blissfully drawing over what the pre-render draws? > Similarly one call a post-render callback and draw over the already > rendered text so user could draw whatever on top of already draw > onverlas and what not. How will the post-render know where it can and where it cannot draw? Or even where to draw, for that matter (assuming you want to do something more useful than just put the same pixels in the same pixel coordinates)? For example, if the window scrolls, wouldn't you want the graphics drawn by these pre/post-renderers to move on display as well, at least sometimes? If you do, how can you do that without knowing some details about the scroll? > It is just how z-buffer works and it would mean z order from pre-render, > normal render (as it is now) and post render as implicit z-depths. AFIU, z-buffer doesn't care to obscure what's displayed below. is this what you have in mind: obscuring the "normal" display with some graphics? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 14:18 ` Eli Zaretskii @ 2020-04-30 14:58 ` Arthur Miller 2020-04-30 17:30 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Arthur Miller @ 2020-04-30 14:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Arthur Miller <arthur.miller@live.com> >> Date: Thu, 30 Apr 2020 15:11:10 +0200 >> Cc: tomas@tuxteam.de, emacs-devel@gnu.org >> >> I have a question here about display: when lisp engine decides to draw >> the display, how difficult would it be to add a callback for pre- and >> post render? > > I don't think I understand the question. It is trivial to add a call I am probably not so clear in my writing, but what I mean is, can it be impelemnted as a hook/callback, to enter same redisplay machinery several times. As you described in other mails how redisplay is figuring out what draw, everything has to come from buffers that are essentially glyph matrices etc. Whatever entry in that machinery is now, can't we just have a list of hooks that each call into that machinery? Normally there would be just one such so Emacs work as it is now, but user could add one before or after, or several do do some extra drawing. > to a Lisp function anywhere in Emacs, the question is what thats > function will be able to do to be useful. Essentially it would be like layered rendering. Imagine Gimp layers. Since each hook is drawing it's own stuff it would be like a layer. For example, if Emacs exposed some graphics stuff like say: draw-this, fill-that, and if drawing layered, like in post-render, that wouldn't collide with overlays and other stuff, one could draw over images etc. Similarly a pre-render could put some graphics and images that appear as a background below normal buffer text. > If the called Lisp can do > anything it wants, then how can it be useful without knowing a whole > lot about the window layout, and what was just now, or will be in a > moment, drawn on it, and in which parts? Each hook woul have it's own associated buffer, which could be same as current buffer or different one (say an temporary with an image in it). Redisplay engine can then just do whatever it does now to figure out that buffer so no changes to redisplay engine. Yes, it would draw in same pixel coordinates of the window it is drawing on. The only hard part would be to figure out how to trigger redisplay engine when some of buffers with associated hooks changes (I think, but I am not knowledgable enough about implementation details here). >> Prerender callback could be any user lisp function called >> that do anything it wants, say draw something on the screen as it owned >> window itself. Than render engine would it's ordinary rendering drawing >> just as it does now, pretending that there was nothing already drawn, so >> it would mean no change at all to current c code for rendering. > > So how do we prevent the display engine from blissfully drawing over > what the pre-render draws? You don't! It is exactly my point to redraw over stuff. Render should re-draw over what pre-render has drawn etc. That way, if a pre-render hook, draws say a buffer with an image in it, then ordinary buffer can draw it's text over it and image would appear as a background in final view. >> Similarly one call a post-render callback and draw over the already >> rendered text so user could draw whatever on top of already draw >> onverlas and what not. > > How will the post-render know where it can and where it cannot draw? > Or even where to draw, for that matter (assuming you want to do > something more useful than just put the same pixels in the same pixel > coordinates)? Actually sometimes, you do want to just put pixels in same pixel coordinates :-). But anyway, one could draw some lines below/above text in buffers, rectangles, and so on. Info about where and what to draw comes well from user code. User's elisp can figure out where and what to draw by examining the buffer and window with usual elisp we have now? > For example, if the window scrolls, wouldn't you want > the graphics drawn by these pre/post-renderers to move on display as > well, at least sometimes? If you do, how can you do that without > knowing some details about the scroll? Of course. Wouldn't came out automatically, by redisplay engine as it already is? >> It is just how z-buffer works and it would mean z order from pre-render, >> normal render (as it is now) and post render as implicit z-depths. > > AFIU, z-buffer doesn't care to obscure what's displayed below. is > this what you have in mind: obscuring the "normal" display with some > graphics? No I didn't, I had in mind to redraw stuff, so user can draw below or above whatever Emacs normally draws. Yeah sure if user chooses to draw two different text buffers on top of each other it would be a mess, but I don't think that is an issue because, normally, probably nobody want's to draw to text files on top of each other. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 14:58 ` Arthur Miller @ 2020-04-30 17:30 ` Eli Zaretskii 2020-05-01 14:32 ` Arthur Miller 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 17:30 UTC (permalink / raw) To: Arthur Miller; +Cc: tomas, emacs-devel > From: Arthur Miller <arthur.miller@live.com> > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Thu, 30 Apr 2020 16:58:10 +0200 > > > For example, if the window scrolls, wouldn't you want > > the graphics drawn by these pre/post-renderers to move on display as > > well, at least sometimes? If you do, how can you do that without > > knowing some details about the scroll? > Of course. Wouldn't came out automatically, by redisplay engine as it > already is? No, of course not. > No I didn't, I had in mind to redraw stuff, so user can draw below or > above whatever Emacs normally draws. > > Yeah sure if user chooses to draw two different text buffers on top of > each other it would be a mess, but I don't think that is an issue > because, normally, probably nobody want's to draw to text files on top > of each other. I think what you describe doesn't fit with how the redisplay works, but I'm probably missing something, since Stefan also thinks this could work. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 17:30 ` Eli Zaretskii @ 2020-05-01 14:32 ` Arthur Miller 0 siblings, 0 replies; 53+ messages in thread From: Arthur Miller @ 2020-05-01 14:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Arthur Miller <arthur.miller@live.com> >> Cc: tomas@tuxteam.de, emacs-devel@gnu.org >> Date: Thu, 30 Apr 2020 16:58:10 +0200 >> >> > For example, if the window scrolls, wouldn't you want >> > the graphics drawn by these pre/post-renderers to move on display as >> > well, at least sometimes? If you do, how can you do that without >> > knowing some details about the scroll? >> Of course. Wouldn't came out automatically, by redisplay engine as it >> already is? > > No, of course not. > >> No I didn't, I had in mind to redraw stuff, so user can draw below or >> above whatever Emacs normally draws. >> >> Yeah sure if user chooses to draw two different text buffers on top of >> each other it would be a mess, but I don't think that is an issue >> because, normally, probably nobody want's to draw to text files on top >> of each other. > > I think what you describe doesn't fit with how the redisplay works, > but I'm probably missing something, since Stefan also thinks this > could work. To be honest I am not sure myself if it could or not work, that is why I posed at as a question in my first mail. I am not so familiar with Emacs internal but I do find it intersting to look at C code from time to time :-). My idea is to make it as least intrusive on current pipeline as possible. I see current drawing stuff as it draws to one (implicit) layer: the current window (I mean OS window). The idea is to wrap it in some way (as a callback) and call in it "per layer" each time, where each layer would draw it's own bufer. This way no new objects are needed, no new concepts, just to redraw buffers in same window once per callback. It does not have to be a callback. Instead it could be a list of buffers to draw just in ordinary list; a qeue to draw from first to last. Same code it does now, just re-enter it again per each buffer, and draw them on top of each other. I am not sure where and how to fit it in. What this be per-buffer, or per-window, or even-per frame? I was looking at Window and Buffer structures, but I don't know myself, to be honest. Then if we could get some graphics functions that draw to say XPixmap or Cairo surface (which should be trivial to expose), we could draw graphics to an image, and then display image in one layer and draw text into another layer. It would give a "Canvas" like functionality and layered rendering. How it would be usefull is up to users, but if we look at what people do in Emacs, all this UML with Ditaa, vertical lines with characters etc, obviosly there is some need for graphics in Emacs. I am sure some powerline users would be happy to draw some cool graphics to their modeline. While drawing to image and layering stuff below/above text buffer is not THE most efficient way, it could still be more efficient then drawing to SVG (xml) and rendering svg and display it as image anway or doing canvas with "put pixel" stuff. Also, not a perfect, but as rest of Emacs implementation, probably *good enough* for many uses? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 17:27 ` Eli Zaretskii 2020-04-29 17:38 ` Eli Zaretskii @ 2020-04-29 18:51 ` tomas 2020-04-29 19:03 ` Eli Zaretskii 1 sibling, 1 reply; 53+ messages in thread From: tomas @ 2020-04-29 18:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2044 bytes --] On Wed, Apr 29, 2020 at 08:27:53PM +0300, Eli Zaretskii wrote: > > Date: Wed, 29 Apr 2020 19:16:19 +0200 > > From: <tomas@tuxteam.de> > > > > > Drawing over normal text, if we don't want to redesign the entire > > > display engine, needs some new kind of "display element" ( a sibling > > > to "character", "image", "stretch", etc.), one that doesn't > > > necessarily have any effect on the metrics of the screen lines it is > > > drawn upon. I'm not sure I have a clear idea about what features such > > > a drawing will need to support, but it could be possible to add such > > > an element with not too much effort. Would someone want to come up > > > with a reasonable list of requirements for such a feature? > > > > That sounds... exciting. Basically, Emacs would have to have a "display > > list" of graphical elements to draw, each one perhaps having a bounding > > box (to discard those from redisplay which aren't currently visible) > > and perhaps a "layer" (more to the background or foreground). > > That's not how Emacs controls what's on display. It basically > represents each window as a 2D array of glyphs, each one of which has > a certain graphical representation. ...a display list of sorts. > The representation itself is of > no concern to the display engine (well, almost); the only thing it > cares about is the metrics of each glyph, because that's what it needs > to do layout calculations. A graphical overlay wouldn't have "glyph metrics", the graphical objects would (I think) have "absolute" [1] positions (possibly precalculated by something else). > We need to try to fit into this framework, if possible. I think the "interesting" problem is to know (quickly) which graphical objects intersect the (visible) window -- something graphics programs do as their main job. Cheers [1] Well, absolute is relative ;-) perhaps anchored at some text in the buffer, perhaps anchored to the window... I don't know. -- tomás [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 18:51 ` tomas @ 2020-04-29 19:03 ` Eli Zaretskii 2020-04-29 19:08 ` tomas 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 19:03 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 20:51:28 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > That's not how Emacs controls what's on display. It basically > > represents each window as a 2D array of glyphs, each one of which has > > a certain graphical representation. > > ...a display list of sorts. It's a far cry from any "list" in my book... > > The representation itself is of > > no concern to the display engine (well, almost); the only thing it > > cares about is the metrics of each glyph, because that's what it needs > > to do layout calculations. > > A graphical overlay wouldn't have "glyph metrics", the graphical > objects would (I think) have "absolute" [1] positions (possibly > precalculated by something else). The position is basically determined by the place in a buffer or a string where they were found. > I think the "interesting" problem is to know (quickly) which > graphical objects intersect the (visible) window -- something > graphics programs do as their main job. That's easy, we have infrastructure for that already -- it is used in expose_frame and its subroutines. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:03 ` Eli Zaretskii @ 2020-04-29 19:08 ` tomas 2020-04-29 19:25 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: tomas @ 2020-04-29 19:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1066 bytes --] On Wed, Apr 29, 2020 at 10:03:00PM +0300, Eli Zaretskii wrote: > > Date: Wed, 29 Apr 2020 20:51:28 +0200 > > From: tomas@tuxteam.de > > Cc: emacs-devel@gnu.org > > > > > That's not how Emacs controls what's on display. It basically > > > represents each window as a 2D array of glyphs, each one of which has > > > a certain graphical representation. > > > > ...a display list of sorts. > > It's a far cry from any "list" in my book... Don't take the "list" too literally. I was possibly misusing (by extension) some now-obsolete graphics jargon. > > I think the "interesting" problem is to know (quickly) which > > graphical objects intersect the (visible) window -- something > > graphics programs do as their main job. > > That's easy, we have infrastructure for that already -- it is used in > expose_frame and its subroutines. This sounds... encouraging :-) (TBH I was coming from the other side: index the graphics objects in a way that one doesn't need to look at most of those which are currently hidden). Cheers -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:08 ` tomas @ 2020-04-29 19:25 ` Eli Zaretskii 2020-04-29 19:59 ` tomas 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 19:25 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 21:08:54 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > > I think the "interesting" problem is to know (quickly) which > > > graphical objects intersect the (visible) window -- something > > > graphics programs do as their main job. > > > > That's easy, we have infrastructure for that already -- it is used in > > expose_frame and its subroutines. > > This sounds... encouraging :-) > > (TBH I was coming from the other side: index the graphics objects > in a way that one doesn't need to look at most of those which > are currently hidden). The current display engine works by screen lines, so if we want to keep it, we must use the existing framework. When a portion of a window is exposed, we redraw all the glyphs in the exposed area(s), and we find the glyphs that need to be redrawn by comparing their coordinates with those of the exposed rectangle(s). ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:25 ` Eli Zaretskii @ 2020-04-29 19:59 ` tomas 2020-04-30 1:19 ` Stefan Monnier 2020-04-30 13:33 ` Eli Zaretskii 0 siblings, 2 replies; 53+ messages in thread From: tomas @ 2020-04-29 19:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 913 bytes --] On Wed, Apr 29, 2020 at 10:25:04PM +0300, Eli Zaretskii wrote: [...] > The current display engine works by screen lines, so if we want to > keep it, we must use the existing framework. Now imagine there's a (graphical) line going from (text) display line 3 to 7. You are not implying that we have to segment that into four chunks, one per text line? > When a portion of a > window is exposed, we redraw all the glyphs in the exposed area(s), > and we find the glyphs that need to be redrawn by comparing their > coordinates with those of the exposed rectangle(s). ... but rather that we intersect the exposed area(s) with each [1] of the graphical objects and redraw that (be it before or after the text)? Cheers [1] conceptually; in reality we'll need some index structure to avoid looking at most of the graphical objects. Quad- trees, whatever. -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:59 ` tomas @ 2020-04-30 1:19 ` Stefan Monnier 2020-04-30 6:55 ` tomas ` (3 more replies) 2020-04-30 13:33 ` Eli Zaretskii 1 sibling, 4 replies; 53+ messages in thread From: Stefan Monnier @ 2020-04-30 1:19 UTC (permalink / raw) To: tomas; +Cc: Eli Zaretskii, emacs-devel > Now imagine there's a (graphical) line going from (text) display > line 3 to 7. You are not implying that we have to segment that > into four chunks, one per text line? I think it would make more sense to treat the overlaid canvas as a completely separate pixmap: when we get an request to redraw a particular area of the screen, we'd ask the current redisplay code to redraw the corresponding text content and then we'd ask the canvas code to draw on top of it. So for rendering of the canvas code we don't need to know which part of the canvas cover which characters, we just render the glyph matrix into a pixmap, render the canvas into another pixmap and then combine them onto the screen. Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 1:19 ` Stefan Monnier @ 2020-04-30 6:55 ` tomas 2020-04-30 12:03 ` Stefan Monnier 2020-04-30 8:04 ` Po Lu ` (2 subsequent siblings) 3 siblings, 1 reply; 53+ messages in thread From: tomas @ 2020-04-30 6:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 939 bytes --] On Wed, Apr 29, 2020 at 09:19:51PM -0400, Stefan Monnier wrote: > > Now imagine there's a (graphical) line going from (text) display > > line 3 to 7. You are not implying that we have to segment that > > into four chunks, one per text line? > > I think it would make more sense to treat the overlaid canvas as > a completely separate pixmap: when we get an request to redraw > a particular area of the screen, we'd ask the current redisplay code to > redraw the corresponding text content and then we'd ask the canvas code > to draw on top of it. So for rendering of the canvas code we don't need > to know which part of the canvas cover which characters, we just render > the glyph matrix into a pixmap, render the canvas into another pixmap > and then combine them onto the screen. This is sounding more and more like a compositor :-) Nit: perhaps we'd like to have pics below as well as above text. Cheers -- t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 6:55 ` tomas @ 2020-04-30 12:03 ` Stefan Monnier 2020-04-30 12:50 ` tomas 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2020-04-30 12:03 UTC (permalink / raw) To: tomas; +Cc: Eli Zaretskii, emacs-devel > This is sounding more and more like a compositor :-) Yes, the combination of the glyph matrix and the canvas is done by "a compositor", indeed. But it's a kind of "trivial" version of a compositor, and it's a very small part of the work (the work taking place mostly on the canvas side where we'll need to draw at positions that depend on the glyph matrix). > Nit: perhaps we'd like to have pics below as well as above text. Not sure if the benefit is worth adding complexity for that. But maybe it's easy and natural to make the layering between glyph matrix and canvas into an arbitrary stack of layers. E.g. I could imagine a design where windows can display a stack of buffers layered one on top of the other (where typically only one of them contains text and the rest only contains canvas objects). But "synchronizing" the canvas in one buffer with the text in the other buffer would likely be more difficult than if we add a canvas "overlay" directly to the buffers. Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 12:03 ` Stefan Monnier @ 2020-04-30 12:50 ` tomas 0 siblings, 0 replies; 53+ messages in thread From: tomas @ 2020-04-30 12:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1669 bytes --] On Thu, Apr 30, 2020 at 08:03:35AM -0400, Stefan Monnier wrote: > > This is sounding more and more like a compositor :-) > > Yes, the combination of the glyph matrix and the canvas is done by > "a compositor", indeed. But it's a kind of "trivial" version of > a compositor, and it's a very small part of the work (the work taking > place mostly on the canvas side where we'll need to draw at positions > that depend on the glyph matrix). Yes, one would probably want to anchor a graphics object to some position in the (text) buffer. > > Nit: perhaps we'd like to have pics below as well as above text. > > Not sure if the benefit is worth adding complexity for that. > But maybe it's easy and natural to make the layering between glyph > matrix and canvas into an arbitrary stack of layers. AFAIK Cairo supports painting on layers; so each graphics object could carry a layer (encoded e.g. as an int) and drawing operations could proceed sorted by that. > E.g. I could imagine a design where windows can display a stack of > buffers layered one on top of the other (where typically only one of > them contains text and the rest only contains canvas objects). > But "synchronizing" the canvas in one buffer with the text in the other > buffer would likely be more difficult than if we add a canvas "overlay" > directly to the buffers. I envision the thing rather as a collection of graphics objects which are rendered to the same surface as the text. The Cairo backend makes that easy, but I don't see why a plain X backend would prevent that either (I have no idea about how things are on Windows or Mac). Cheers -- tomás [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 1:19 ` Stefan Monnier 2020-04-30 6:55 ` tomas @ 2020-04-30 8:04 ` Po Lu 2020-04-30 12:08 ` Stefan Monnier 2020-04-30 13:55 ` Eli Zaretskii 2020-04-30 13:46 ` Eli Zaretskii 2020-04-30 14:27 ` Drew Adams 3 siblings, 2 replies; 53+ messages in thread From: Po Lu @ 2020-04-30 8:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: tomas, Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > I think it would make more sense to treat the overlaid canvas as > a completely separate pixmap: when we get an request to redraw > a particular area of the screen, we'd ask the current redisplay code to > redraw the corresponding text content and then we'd ask the canvas code > to draw on top of it. So for rendering of the canvas code we don't need > to know which part of the canvas cover which characters, we just render > the glyph matrix into a pixmap, render the canvas into another pixmap > and then combine them onto the screen. That's what I'm trying to do right now, but so far keeping track of exactly where each canvas is displayed on the screen seems to be difficult. I'd appreciate some suggestions, thanks. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 8:04 ` Po Lu @ 2020-04-30 12:08 ` Stefan Monnier 2020-04-30 13:55 ` Eli Zaretskii 1 sibling, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2020-04-30 12:08 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, tomas, emacs-devel >> I think it would make more sense to treat the overlaid canvas as >> a completely separate pixmap: when we get an request to redraw >> a particular area of the screen, we'd ask the current redisplay code to >> redraw the corresponding text content and then we'd ask the canvas code >> to draw on top of it. So for rendering of the canvas code we don't need >> to know which part of the canvas cover which characters, we just render >> the glyph matrix into a pixmap, render the canvas into another pixmap >> and then combine them onto the screen. > > That's what I'm trying to do right now, but so far keeping track of > exactly where each canvas is displayed on the screen seems to be > difficult. I was thinking of having just one canvas per (Emacs) window. > I'd appreciate some suggestions, thanks. I can help with type system and compiler design. But I have no practical experience with graphical APIs, sadly. Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 8:04 ` Po Lu 2020-04-30 12:08 ` Stefan Monnier @ 2020-04-30 13:55 ` Eli Zaretskii 2020-05-01 23:27 ` Po Lu 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 13:55 UTC (permalink / raw) To: Po Lu; +Cc: tomas, monnier, emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: tomas@tuxteam.de, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > Date: Thu, 30 Apr 2020 16:04:38 +0800 > > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > That's what I'm trying to do right now, but so far keeping track of > exactly where each canvas is displayed on the screen seems to be > difficult. I'd appreciate some suggestions, thanks. I think the information needs to be recorded in the glyph structure that represents a canvas. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 13:55 ` Eli Zaretskii @ 2020-05-01 23:27 ` Po Lu 2020-05-02 6:51 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Po Lu @ 2020-05-01 23:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I think the information needs to be recorded in the glyph structure > that represents a canvas. I have a canvas field inside `struct glyph' that points to the canvas object. What I'm trying to do right now is track the position of the canvases on-screen, so I can draw them separately from redisplay. I'd appreciate some suggestions, thanks. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-05-01 23:27 ` Po Lu @ 2020-05-02 6:51 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-05-02 6:51 UTC (permalink / raw) To: Po Lu; +Cc: tomas, monnier, emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: tomas@tuxteam.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 02 May 2020 07:27:07 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > I think the information needs to be recorded in the glyph structure > > that represents a canvas. > > I have a canvas field inside `struct glyph' that points to the canvas > object. It is not a good idea to have pointers in the glyph structure. (Yes, xwidget uses that, but don't take example from that, please.) A glyph should be self-describing from the metrics POV. If you need additional information (beyond the basic metrics), use the example of images and faces: we cache the objects and record their cache ID in the glyph. > What I'm trying to do right now is track the position of the > canvases on-screen, so I can draw them separately from redisplay. My suggestion is not to "draw separately from redisplay". I don't see how this could work, unless you also modify extensively how the second phase of redisplay, the one entered via update_frame and update_window, works. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 1:19 ` Stefan Monnier 2020-04-30 6:55 ` tomas 2020-04-30 8:04 ` Po Lu @ 2020-04-30 13:46 ` Eli Zaretskii 2020-04-30 14:37 ` Stefan Monnier 2020-04-30 14:27 ` Drew Adams 3 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 13:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: tomas, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 21:19:51 -0400 > > I think it would make more sense to treat the overlaid canvas as > a completely separate pixmap: when we get an request to redraw > a particular area of the screen, we'd ask the current redisplay code to > redraw the corresponding text content and then we'd ask the canvas code > to draw on top of it. Unfortunately, most redisplay cycles don't start from a request to redraw a particular area of the screen. This only happens when we get expose events from the WM, which is not the "normal" trigger of redisplay. Usually, redisplay is entered when Emacs is idle, and it's one of the display engine's main jobs to figure out what parts of which windows need to be redrawn, by just considering the changes in buffer text, their properties/overlays, and window geometry and starting point. In doing so, the display engine need to know, up front, which parts of the display reside where on the screen, whether any of them needs to be redrawn because the underlying Lisp data was modified by some command since the last redisplay. So AFAIU it won't work to redraw the "canvas" only when the text beneath it changes; the display engine needs to be able to redraw the canvas itself even if the text didn't change, and it needs to know which portions of the window are affected by the canvas in order to make decisions regarding how to redraw the window optimally. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 13:46 ` Eli Zaretskii @ 2020-04-30 14:37 ` Stefan Monnier 2020-04-30 17:27 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2020-04-30 14:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel >> I think it would make more sense to treat the overlaid canvas as >> a completely separate pixmap: when we get an request to redraw >> a particular area of the screen, we'd ask the current redisplay code to >> redraw the corresponding text content and then we'd ask the canvas code >> to draw on top of it. > > Unfortunately, most redisplay cycles don't start from a request to > redraw a particular area of the screen. I don't think it makes a big difference. Upon redisplay, the glyph-matrix layer will compute which parts of the window needs updates in the that layer (exactly like it currently does), and the canvas will do its own computation of which part of it needs updating (presumably this will be handled by the external canvas library such as Cairo's rather than by Emacs's own code) and then the compositing layer will figure out how to combine those two changes. IIUC libraries like Cairo already provide functionality to do compositing of layers, so that would take care of that part as well. Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 14:37 ` Stefan Monnier @ 2020-04-30 17:27 ` Eli Zaretskii 2020-04-30 18:22 ` Stefan Monnier 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 17:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: tomas, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Thu, 30 Apr 2020 10:37:03 -0400 > > > Unfortunately, most redisplay cycles don't start from a request to > > redraw a particular area of the screen. > > I don't think it makes a big difference. Upon redisplay, the > glyph-matrix layer will compute which parts of the window needs updates > in the that layer (exactly like it currently does), and the canvas will > do its own computation of which part of it needs updating (presumably > this will be handled by the external canvas library such as Cairo's > rather than by Emacs's own code) and then the compositing layer will > figure out how to combine those two changes. I don't think I understand how this would fit into the current redisplay framework. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 17:27 ` Eli Zaretskii @ 2020-04-30 18:22 ` Stefan Monnier 2020-04-30 18:42 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2020-04-30 18:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel > I don't think I understand how this would fit into the current > redisplay framework. I think it should basically not require touching xdisp.c. It should work at the level of `update_window` only. Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 18:22 ` Stefan Monnier @ 2020-04-30 18:42 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 18:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: tomas, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Thu, 30 Apr 2020 14:22:02 -0400 > > > I don't think I understand how this would fit into the current > > redisplay framework. > > I think it should basically not require touching xdisp.c. > It should work at the level of `update_window` only. I _am_ talking about update_frame and update_window. They have their own ideas about which parts of the screen need to be updated and which don't, and how they should be updated (whether by scrolling or by deletion and insertion or by overwriting). Those ideas are based on the assumption that they know what is currently on the glass. That knowledge comes from the glyph matrices. If the canvasses are drawn independently of the glyph matrices, then update_window will make wrong decisions, and the result will be a royal mess on the screen. Maybe I'm missing something, but you didn't actually explain on any level of detail how do you propose to "compose" the "normal" display with the canvasses. How about if you try to describe your ideas in two simple use cases: (1) when a canvas that was on display, overlaying some text, is deleted (and nothing else is changed); and (2) when update_window decides to scroll some part of a window which has a canvas partially overlaying the text in the part to be scrolled? ^ permalink raw reply [flat|nested] 53+ messages in thread
* RE: Emacs canvas support 2020-04-30 1:19 ` Stefan Monnier ` (2 preceding siblings ...) 2020-04-30 13:46 ` Eli Zaretskii @ 2020-04-30 14:27 ` Drew Adams 3 siblings, 0 replies; 53+ messages in thread From: Drew Adams @ 2020-04-30 14:27 UTC (permalink / raw) To: Stefan Monnier, tomas; +Cc: Eli Zaretskii, emacs-devel > I think it would make more sense to treat the overlaid canvas as > a completely separate pixmap: when we get an request to redraw > a particular area of the screen, we'd ask the current redisplay code to > redraw the corresponding text content and then we'd ask the canvas code > to draw on top of it. So for rendering of the canvas code we don't > need to know which part of the canvas cover which characters, we just > render the glyph matrix into a pixmap, render the canvas into another > pixmap and then combine them onto the screen. Exactly what I was thinking/wondering, as someone totally naive in this area. If we're after a graphic canvas (editing with pixels), why involve glyphs/chars at all, for that space? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:59 ` tomas 2020-04-30 1:19 ` Stefan Monnier @ 2020-04-30 13:33 ` Eli Zaretskii 2020-04-30 13:52 ` Arthur Miller 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 13:33 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Wed, 29 Apr 2020 21:59:30 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > The current display engine works by screen lines, so if we want to > > keep it, we must use the existing framework. > > Now imagine there's a (graphical) line going from (text) display > line 3 to 7. You are not implying that we have to segment that > into four chunks, one per text line? That's one way, but it's ugly and complicated. > > > When a portion of a > > window is exposed, we redraw all the glyphs in the exposed area(s), > > and we find the glyphs that need to be redrawn by comparing their > > coordinates with those of the exposed rectangle(s). > > ... but rather that we intersect the exposed area(s) with each [1] > of the graphical objects and redraw that (be it before or after the > text)? Yes, but we examine what you call "objects" by screen lines. > [1] conceptually; in reality we'll need some index structure > to avoid looking at most of the graphical objects. Quad- > trees, whatever. We don't use them now. A typical window is not large enough to make that a worthy complication. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 13:33 ` Eli Zaretskii @ 2020-04-30 13:52 ` Arthur Miller 0 siblings, 0 replies; 53+ messages in thread From: Arthur Miller @ 2020-04-30 13:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tomas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Wed, 29 Apr 2020 21:59:30 +0200 >> From: tomas@tuxteam.de >> Cc: emacs-devel@gnu.org >> >> > The current display engine works by screen lines, so if we want to >> > keep it, we must use the existing framework. >> >> Now imagine there's a (graphical) line going from (text) display >> line 3 to 7. You are not implying that we have to segment that >> into four chunks, one per text line? > > That's one way, but it's ugly and complicated. > >> >> > When a portion of a >> > window is exposed, we redraw all the glyphs in the exposed area(s), >> > and we find the glyphs that need to be redrawn by comparing their >> > coordinates with those of the exposed rectangle(s). >> >> ... but rather that we intersect the exposed area(s) with each [1] >> of the graphical objects and redraw that (be it before or after the >> text)? > > Yes, but we examine what you call "objects" by screen lines. > >> [1] conceptually; in reality we'll need some index structure >> to avoid looking at most of the graphical objects. Quad- >> trees, whatever. > > We don't use them now. A typical window is not large enough to make > that a worthy complication. If you used exactly same functionality as now, but would call it twice, or N number of times, as a chain of render hooks, and then let every callback in chain draw it's own buffer, wouldn't that solve the issue with relatively small effort in changes? If user had pre-render hook, and say created an image and put it in first char in temp buffer and then add that buffer as pre-render hook, then the render engine just need to be modified to act when any of buffers in render chain changes, instead of just current buffer. But when it comes to rendering functionality, it would stay same, just call whatever you already have now for the buffer drawing, on each render hook and it's associated buffer and let them draw over each other; like in z-buffer. Is it too difficult to implement? It would draw over some portions of screen twice or more times, but who cares. I don't think it is a big issue in an application like Emacs, it is not like Emacs is drawing millions of polygons at 120 FPS. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 16:54 ` Eli Zaretskii 2020-04-29 17:16 ` tomas @ 2020-04-29 19:23 ` David Engster 2020-04-30 13:29 ` Eli Zaretskii 2020-04-30 6:52 ` Corwin Brust 2 siblings, 1 reply; 53+ messages in thread From: David Engster @ 2020-04-29 19:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, emacs-devel >> From: David Engster <deng@randomsample.de> >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org >> Date: Wed, 29 Apr 2020 18:14:55 +0200 > >> >> IMHO, What would be much more exciting, is if you could draw directly >> over normal text. This would enable a whole new set of >> possibilities. For instance, I always liked visual diff tools like >> 'Meld' or 'Code Compare', but I don't see how you could do this with >> Emacs. Or things like proper indentation guides, or widgets inside text >> for code folding. Yes, those can be done in Emacs today, but it is very >> difficult to get right and often not really satisfactory (weird >> interactions between packages, too slow, etc.). > > AFAIU, Meld seems to draw the graphics _between_ windows, and only > highlights the source lines with background colors. I think we can do > that if we use an extra window in-between the two being compared, and > put images in that extra window to show the graphical description of > the changes between the two versions. I actually tried exactly that, many years ago. I dimly remember that handling the coordinates was pretty complicated and it was slow. Like, orders of magnitude too slow, even with the simplest and fastest image types. There was no way you would ever be able to scroll text and update the diff visualization alongside it. It was just a flickery mess. It would of course be possible to visualize the diff in an idle timer and not during scrolling, but that is exactly what I mean above with "not really satisfactory", so I gave up. > Drawing over normal text, if we don't want to redesign the entire > display engine, needs some new kind of "display element" ( a sibling > to "character", "image", "stretch", etc.), one that doesn't > necessarily have any effect on the metrics of the screen lines it is > drawn upon. I'm not sure I have a clear idea about what features such > a drawing will need to support, but it could be possible to add such > an element with not too much effort. Would someone want to come up > with a reasonable list of requirements for such a feature? When I played around with it, I thought a first iteration could be to simply expose the basic Cairo API to ELisp, which is essentially drawing lines/arcs/rectangles and filling. I thought that maybe it would be possible that one could handle this like a graphical transparent overlay, but I'm afraid I'm way out of my depth here. I have no idea how one would handle scrolling, for instance. -David ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 19:23 ` David Engster @ 2020-04-30 13:29 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 13:29 UTC (permalink / raw) To: David Engster; +Cc: luangruo, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 21:23:30 +0200 > > > AFAIU, Meld seems to draw the graphics _between_ windows, and only > > highlights the source lines with background colors. I think we can do > > that if we use an extra window in-between the two being compared, and > > put images in that extra window to show the graphical description of > > the changes between the two versions. > > I actually tried exactly that, many years ago. I dimly remember that > handling the coordinates was pretty complicated and it was slow. Like, > orders of magnitude too slow, even with the simplest and fastest image > types. There was no way you would ever be able to scroll text and update > the diff visualization alongside it. It was just a flickery mess. It > would of course be possible to visualize the diff in an idle timer and > not during scrolling, but that is exactly what I mean above with "not > really satisfactory", so I gave up. Hmm... yes, I see your point. We'd need to find a way of somehow synchronizing the windows, which is not very easy (witness follow-mode). > > Drawing over normal text, if we don't want to redesign the entire > > display engine, needs some new kind of "display element" ( a sibling > > to "character", "image", "stretch", etc.), one that doesn't > > necessarily have any effect on the metrics of the screen lines it is > > drawn upon. I'm not sure I have a clear idea about what features such > > a drawing will need to support, but it could be possible to add such > > an element with not too much effort. Would someone want to come up > > with a reasonable list of requirements for such a feature? > > When I played around with it, I thought a first iteration could be to > simply expose the basic Cairo API to ELisp, which is essentially drawing > lines/arcs/rectangles and filling. I thought that maybe it would be > possible that one could handle this like a graphical transparent > overlay, but I'm afraid I'm way out of my depth here. I have no idea how > one would handle scrolling, for instance. Right, the main problem is not how to draw, but how to tell the display engine where's the drawing on the screen, and when to redraw it. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 16:54 ` Eli Zaretskii 2020-04-29 17:16 ` tomas 2020-04-29 19:23 ` David Engster @ 2020-04-30 6:52 ` Corwin Brust 2 siblings, 0 replies; 53+ messages in thread From: Corwin Brust @ 2020-04-30 6:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, David Engster, Emacs developers Hi everyone! This is conversation intersects very directly with a project I organize that is creating an RPG game engine and authoring/publishing enhancements based on org-mode and svg.el. Our project is very new and the things that work only work if one is careful and patient. We're targeting whatever will likely be supported in Emacs 28 or so, meaning we would be open to help testing new features that come out of this and similar conversations, if any, and given we're up the tasks. (Our application for savannah hosting is in progress; I've no interest to discuss the project's current non-free hosting solution.) On Wed, Apr 29, 2020 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote: > > > From: David Engster <deng@randomsample.de> > > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > Date: Wed, 29 Apr 2020 18:14:55 +0200 > > > > IMHO, What would be much more exciting, is if you could draw directly > > over normal text. This would enable a whole new set of > > possibilities. > [..] not too much effort. Would someone want to come up > with a reasonable list of requirements for such a feature? To the extent it may help with developing the list you suggested, I wanted to share this SVG image from our project: https://raw.githubusercontent.com/dungeon-mode/game/master/Docs/battleboard/Battleboard.svg This file mocks an important player interface that shows the vital statistics for each of the eight player-characters that compose the "party". The four inner boxes inside each plus-shape create a space for one such statistic, for example, Body Hits, Armor Hit Points, etc. which are displayed integers. These, like the actual text show in the mock, should ideally be text. It seems to me that this should work well with such overlay methods as are discussed down-thread. I hope the graphic provides a useful context for on "in the wild" aspirational use for composed SVG+text in user-space. I'm happy to be pulled into other threads/conversations related to enhancing display options for hybrid text and SVG. PS, For the "mapping" feature (the party controls their movement through a maze), which is the only truly implicitly graphical component we are creating, we have resorted.to drawing text overlays with the "text" SVG element; however, for the battle-board, we had been planning to use a window for each character (so eight windows) and slices within to achieve the crisp lines and while allowing some room for some theming. -- Corwin 612-217-1742 612-298-0615 (fax) 612-695-4276 (mobile) corwin.brust (skype) corwin@bru.st ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 16:14 ` David Engster 2020-04-29 16:54 ` Eli Zaretskii @ 2020-04-29 17:08 ` Eli Zaretskii 2020-04-29 20:14 ` David Engster 1 sibling, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-29 17:08 UTC (permalink / raw) To: David Engster; +Cc: luangruo, emacs-devel > From: David Engster <deng@randomsample.de> > Date: Wed, 29 Apr 2020 18:14:55 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > [...] things like proper indentation guides, or widgets inside text > for code folding. Would it make sense to put these on the fringes? If yes, this could be done without any changes on the C level, I think. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 17:08 ` Eli Zaretskii @ 2020-04-29 20:14 ` David Engster 2020-04-30 13:35 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: David Engster @ 2020-04-29 20:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, emacs-devel >> From: David Engster <deng@randomsample.de> >> Date: Wed, 29 Apr 2020 18:14:55 +0200 >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org >> >> [...] things like proper indentation guides, or widgets inside text >> for code folding. > > Would it make sense to put these on the fringes? If yes, this could > be done without any changes on the C level, I think. I just found that this exists already with the 'hideshowvis' package and it works reasonably well. So I agree this is not a good use case. You can also do indentation guides in current Emacs, but the packages I tried did not work great. They usually collide with packages like company-mode which are more important to me. This is often the case: if you have several packages that use overlays and/or text properties for fancy stuff, you can expect them to collide in some way. Let's take another very simple example: I often wished it would be possible to tell Emacs "Put an image at pixel position (x,y)" without having to anchor it to some point position. For instance, I have a block of text and would like to have an image next to it. Last I checked, the only way to do this is to create a "sliced image" which automatically gets cut up into rows and columns, but this is a very brittle workaround (it doesn't work with an increased line-spacing, for instance). -David ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 20:14 ` David Engster @ 2020-04-30 13:35 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 13:35 UTC (permalink / raw) To: David Engster; +Cc: luangruo, emacs-devel > From: David Engster <david@engster.org> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 22:14:18 +0200 > > Let's take another very simple example: I often wished it would be > possible to tell Emacs "Put an image at pixel position (x,y)" without > having to anchor it to some point position. For instance, I have a block > of text and would like to have an image next to it. Last I checked, the > only way to do this is to create a "sliced image" which automatically > gets cut up into rows and columns, but this is a very brittle workaround > (it doesn't work with an increased line-spacing, for instance). Under the current design of the display engine, I believe anything displayed inside a window must come from some buffer text position or from a string. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 6:34 ` Emacs canvas support Po Lu via Emacs development discussions. 2020-04-29 8:24 ` Eli Zaretskii @ 2020-04-29 20:48 ` Juri Linkov 2020-04-30 2:36 ` Eli Zaretskii 1 sibling, 1 reply; 53+ messages in thread From: Juri Linkov @ 2020-04-29 20:48 UTC (permalink / raw) To: Po Lu via Emacs development discussions.; +Cc: Po Lu > I'd appreciate some feedback on something I came up with during my spare > time: Emacs canvas support. Great, thanks! I'm going to try to use canvas-rounded-rectangle for rounded corners of tabs. Sometime ago I tried to draw them with Cairo, but the implementation was too ah-hoc. Whereas your solution is more generally usable. Would you put your code on a branch? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-29 20:48 ` Juri Linkov @ 2020-04-30 2:36 ` Eli Zaretskii 2020-04-30 20:20 ` Juri Linkov 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2020-04-30 2:36 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, emacs-devel > From: Juri Linkov <juri@linkov.net> > Date: Wed, 29 Apr 2020 23:48:31 +0300 > Cc: Po Lu <luangruo@yahoo.com> > > > I'd appreciate some feedback on something I came up with during my spare > > time: Emacs canvas support. > > Great, thanks! I'm going to try to use canvas-rounded-rectangle > for rounded corners of tabs. Sometime ago I tried to draw them > with Cairo, but the implementation was too ah-hoc. Whereas your > solution is more generally usable. Did you try using svg.el? > Would you put your code on a branch? We need to finish the legal paperwork first. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 2:36 ` Eli Zaretskii @ 2020-04-30 20:20 ` Juri Linkov 2020-05-01 6:01 ` Eli Zaretskii 0 siblings, 1 reply; 53+ messages in thread From: Juri Linkov @ 2020-04-30 20:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, emacs-devel [-- Attachment #1: Type: text/plain, Size: 955 bytes --] >> > I'd appreciate some feedback on something I came up with during my spare >> > time: Emacs canvas support. >> >> Great, thanks! I'm going to try to use canvas-rounded-rectangle >> for rounded corners of tabs. Sometime ago I tried to draw them >> with Cairo, but the implementation was too ah-hoc. Whereas your >> solution is more generally usable. > > Did you try using svg.el? I tried, but svg is not great, it has many unfixed problems with scaling and backgrounds. OTOH, I hope with canvas it would be easy to draw such shapes around the tab name like in web browsers shown below, and also to implement overlapping tabs. At least canvas in web browsers allow doing such custom drawings. As for the implementation, there is already Cairo code used to draw 3D box shapes around strings with box faces in xterm.c. Canvas could be implemented to generalize these hard-coded shapes and expose their definitions to Lisp as configurable options. [-- Attachment #2: browser_tab.png --] [-- Type: image/png, Size: 1920 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Emacs canvas support 2020-04-30 20:20 ` Juri Linkov @ 2020-05-01 6:01 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2020-05-01 6:01 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, emacs-devel > From: Juri Linkov <juri@linkov.net> > Cc: emacs-devel@gnu.org, luangruo@yahoo.com > Date: Thu, 30 Apr 2020 23:20:18 +0300 > > > Did you try using svg.el? > > I tried, but svg is not great, it has many unfixed problems with scaling > and backgrounds. Cannot these bugs be fixed? > OTOH, I hope with canvas it would be easy to draw such shapes around > the tab name like in web browsers shown below, and also to implement > overlapping tabs. At least canvas in web browsers allow doing such > custom drawings. The problem with canvas is that we have yet to figure out how to teach the display engine handle them correctly and efficiently. svg.el doesn't have that problem. ^ permalink raw reply [flat|nested] 53+ messages in thread
![[-- Attachment #2: browser_tab.png --] [-- Type: image/png, Size: 1920 bytes --]](../../87r1w4sp31.fsf@mail.linkov.net/2-browser_tab.png){kind=link}
end of thread, other threads:[~2020-05-02 6:51 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <875zdikdge.fsf.ref@yahoo.com>
2020-04-29 6:34 ` Emacs canvas support Po Lu via Emacs development discussions.
2020-04-29 8:24 ` Eli Zaretskii
2020-04-29 9:57 ` Po Lu
2020-04-29 10:10 ` Eli Zaretskii
2020-04-29 10:22 ` Po Lu
2020-04-29 10:27 ` Po Lu via Emacs development discussions.
2020-04-29 11:47 ` Eli Zaretskii
2020-04-29 10:35 ` Eli Zaretskii
2020-04-29 10:41 ` Po Lu
2020-04-29 11:51 ` Eli Zaretskii
2020-04-29 12:12 ` Po Lu
2020-04-29 16:14 ` David Engster
2020-04-29 16:54 ` Eli Zaretskii
2020-04-29 17:16 ` tomas
2020-04-29 17:27 ` Eli Zaretskii
2020-04-29 17:38 ` Eli Zaretskii
2020-04-30 13:11 ` Arthur Miller
2020-04-30 14:18 ` Eli Zaretskii
2020-04-30 14:58 ` Arthur Miller
2020-04-30 17:30 ` Eli Zaretskii
2020-05-01 14:32 ` Arthur Miller
2020-04-29 18:51 ` tomas
2020-04-29 19:03 ` Eli Zaretskii
2020-04-29 19:08 ` tomas
2020-04-29 19:25 ` Eli Zaretskii
2020-04-29 19:59 ` tomas
2020-04-30 1:19 ` Stefan Monnier
2020-04-30 6:55 ` tomas
2020-04-30 12:03 ` Stefan Monnier
2020-04-30 12:50 ` tomas
2020-04-30 8:04 ` Po Lu
2020-04-30 12:08 ` Stefan Monnier
2020-04-30 13:55 ` Eli Zaretskii
2020-05-01 23:27 ` Po Lu
2020-05-02 6:51 ` Eli Zaretskii
2020-04-30 13:46 ` Eli Zaretskii
2020-04-30 14:37 ` Stefan Monnier
2020-04-30 17:27 ` Eli Zaretskii
2020-04-30 18:22 ` Stefan Monnier
2020-04-30 18:42 ` Eli Zaretskii
2020-04-30 14:27 ` Drew Adams
2020-04-30 13:33 ` Eli Zaretskii
2020-04-30 13:52 ` Arthur Miller
2020-04-29 19:23 ` David Engster
2020-04-30 13:29 ` Eli Zaretskii
2020-04-30 6:52 ` Corwin Brust
2020-04-29 17:08 ` Eli Zaretskii
2020-04-29 20:14 ` David Engster
2020-04-30 13:35 ` Eli Zaretskii
2020-04-29 20:48 ` Juri Linkov
2020-04-30 2:36 ` Eli Zaretskii
2020-04-30 20:20 ` Juri Linkov
2020-05-01 6:01 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).