From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.bugs Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32 Date: Mon, 29 Apr 2019 11:43:23 -0600 Message-ID: <877ebcogg4.fsf@gmail.com> References: <877ebeor2d.fsf@gmail.com> <83tveit5ph.fsf@gnu.org> <87pnp5oqu1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="257542"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: 35468@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 29 19:48:50 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLAOY-0014rA-ER for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 19:48:50 +0200 Original-Received: from localhost ([127.0.0.1]:33092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLAOX-0003Dd-D4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 13:48:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLAJy-0008RH-99 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 13:44:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLAJw-0006cK-4k for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 13:44:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54331) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hLAJu-0006bB-EL for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 13:44:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hLAJu-000379-5n for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Gramiak Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2019 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35468-submit@debbugs.gnu.org id=B35468.155655981411929 (code B ref 35468); Mon, 29 Apr 2019 17:44:02 +0000 Original-Received: (at 35468) by debbugs.gnu.org; 29 Apr 2019 17:43:34 +0000 Original-Received: from localhost ([127.0.0.1]:39641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLAJR-00036L-JQ for submit@debbugs.gnu.org; Mon, 29 Apr 2019 13:43:33 -0400 Original-Received: from mail-pf1-f182.google.com ([209.85.210.182]:45135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLAJP-000368-Dj for 35468@debbugs.gnu.org; Mon, 29 Apr 2019 13:43:32 -0400 Original-Received: by mail-pf1-f182.google.com with SMTP id e24so5661636pfi.12 for <35468@debbugs.gnu.org>; Mon, 29 Apr 2019 10:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=k1jcwuhyWT7dGgnKVfiyXuaw6E4J2JwEMB8NTEfFCAg=; b=e6uvhYN8q/jNdIHArDPVV9U54chsh+qSM2gnGFgwH18rQEfIEhDk9OM63C8w8LYYEl 2pvLqr3xtjb0vKC79kRw4GwxveQ5Fi3D8A767HG4HIAJhYF5oJna0hrToIHDGTO5LxtE SLXNIlE4emQgZXrOqQ/2rnFpd25wbdSvOve+DujCmYZNgwffFJzqHWvxEyCVWsQTlU/a ZqQIREgGVlFJx0pYY3IzPG2SI2yhsw1NtGHqGZFPCKxxLJCjbhg8KADsNOUrLKD5dwrJ kocCsHbhW7lBf5b5eBy/8zA76NmNRapYESCTgJC+EAdVKHSyLrHpEUflVxLUJN6DNY6u oqcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=k1jcwuhyWT7dGgnKVfiyXuaw6E4J2JwEMB8NTEfFCAg=; b=RFJo39TgeIH4w8y05OMf+nG6Wqwc5iSb7FRcD1r8SHQCGKSgFES1n1dqj4l437OqcR 53I6lKPPHRDq/PsNrrA/5cx4yls66JvymCQ1DGBvKy6TElVt3br7tPWlo1e15qez9k1G syG+X2Vsx00Rsqm0WlA1YuawKNuG2SQ77w++9CcR2ZBTdEW1xyEIj9e1aFjgAZ0ZGE/4 blJKChavNjM9pWhSfTLUAx6cqZ/pCTLm4sO/Th604nBXKFYYDWRS4CYQ8IoAMl4Hkye7 xCxp0XSfxeYfvtDU8x3pNvUjW1kvPu3Oj6ch2ezL0OJpmn/h5E5IP9BrSfMO3kEykE31 LpYg== X-Gm-Message-State: APjAAAW4b3hgtuwrUVBFSBI41IIeE2vGNsvFjl+cRwwY5BBcqz/Ck7eV JSnq4ipXVq+LSnBBk/WOpu+EColw X-Google-Smtp-Source: APXvYqyBMvzM/sZrfggDCZUkchgEo3HzcarbuFYcKf0ZhESoejJ3CGUWsErZIL4tOq+PO3/4RHJLEw== X-Received: by 2002:a63:42:: with SMTP id 63mr1929790pga.337.1556559805229; Mon, 29 Apr 2019 10:43:25 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id j16sm44275767pfi.58.2019.04.29.10.43.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 29 Apr 2019 10:43:24 -0700 (PDT) In-Reply-To: <87pnp5oqu1.fsf@gmail.com> (Alex Gramiak's message of "Sun, 28 Apr 2019 13:46:46 -0600") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158438 Archived-At: >> The result of this refactoring should be more low-level and more >> primitive interfaces, and they should each one make sense, not be >> ad-hoc. It means the job becomes more complex, and you will probably >> need to ask questions regarding the GUI systems you are less familiar >> with. But the result will IMO much better and future-proof. > > I'll see what I can do. Alright, for the first question may I ask if you're okay with the following abstraction (which may be the start of a pattern)? I'm in {x,w32}_draw_box_rect right now, trying to generalize both versions. The issue is that the fill command in each accepts different arguments; specifically the w32 version takes in the color explicitly and uses s->hdc instead of s->gc. So I think there will have to be 2 different fill_rectangle interface procedures: one for glyph strings (so that the w32 version can access s->hdc), and another for other procedures like *_draw_bar_cursor. void gui_draw_glyph_string_box (struct glyph_string *s) { int width, left_x, right_x, top_y, bottom_y, last_x; bool raised_p, left_p, right_p; struct glyph *last_glyph; last_x = ((s->row->full_width_p && !s->w->pseudo_window_p) ? WINDOW_RIGHT_EDGE_X (s->w) : window_box_right (s->w, s->area)); /* The glyph that may have a right box line. */ last_glyph = (s->cmp || s->img ? s->first_glyph : s->first_glyph + s->nchars - 1); width = eabs (s->face->box_line_width); raised_p = s->face->box == FACE_RAISED_BOX; left_x = s->x; right_x = (s->row->full_width_p && s->extends_to_end_of_line_p ? last_x - 1 : min (last_x, s->x + s->background_width) - 1); top_y = s->y; bottom_y = top_y + s->height - 1; left_p = (s->first_glyph->left_box_line_p || (s->hl == DRAW_MOUSE_FACE && (s->prev == NULL || s->prev->hl != s->hl))); right_p = (last_glyph->right_box_line_p || (s->hl == DRAW_MOUSE_FACE && (s->next == NULL || s->next->hl != s->hl))); if (s->face->box == FACE_SIMPLE_BOX) FRAME_GDIF (s->f)->draw_box_rect (s, left_x, top_y, right_x, bottom_y, width, left_p, right_p); else { FRAME_GDIF (s->f)->setup_relief_colors (s); FRAME_GDIF (s->f)->draw_relief_rect (s->f, left_x, top_y, right_x, bottom_y, width, raised_p, true, true, left_p, right_p); } } void gui_draw_box_rect (struct glyph_string *s, int left_x, int top_y, int right_x, int bottom_y, int width, bool left_p, bool right_p) { struct graphical_drawing_interface *gdif = FRAME_GDIF (s->f); gdif->save_context (s); gdif->set_context_clip (s); gdif->set_context_foreground (s, s->face->box_color); /* Top. */ gdif->fill_rectangle (s, s->gc, left_x, top_y, right_x - left_x + 1, width); /* Left. */ if (left_p) { gdif->fill_rectangle (s, s->gc, left_x, top_y, width, bottom_y - top_y + 1); } /* Bottom. */ gdif->fill_rectangle (s, s->gc, left_x, bottom_y - width + 1, right_x - left_x + 1, width); /* Right. */ if (right_p) { gdif->fill_rectangle (s, s->gc, right_x - width + 1, top_y, width, bottom_y - top_y + 1); } gdif->reset_context (s); } It doesn't work for NS partially because of the following section only present in the NS equivalent of gui_draw_glyph_string_box. Would you be okay with putting this in the generic version inside a FRAME_NS_P (s->f) check? I don't know why only NS has this, though... if (s->hl == DRAW_MOUSE_FACE) { face = FACE_FROM_ID_OR_NULL (s->f, MOUSE_HL_INFO (s->f)->mouse_face_face_id); if (!face) face = FACE_FROM_ID (s->f, MOUSE_FACE_ID); } else face = s->face;