From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: mituharu@math.s.chiba-u.ac.jp Newsgroups: gmane.emacs.bugs Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32 Date: Sat, 4 May 2019 06:33:05 +0900 Message-ID: <1e1cbd7fdb42983a334d32e6675e31f0.squirrel@weber.math.s.chiba-u.ac.jp> References: <877ebeor2d.fsf@gmail.com> <83tveit5ph.fsf@gnu.org> <87pnp5oqu1.fsf@gmail.com> <877ebcogg4.fsf@gmail.com> <83sgu0rsue.fsf@gnu.org> <8736lznzjf.fsf@gmail.com> <877eb7l5vl.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="119024"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.22-5.el6 Cc: 35468@debbugs.gnu.org To: "Alex Gramiak" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:34:11 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 1hMfop-000Uhb-7V for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:34:11 +0200 Original-Received: from localhost ([127.0.0.1]:47494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMfoo-0005cj-1u for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 17:34:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMfoh-0005cd-Bb for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 17:34:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMfof-0000QU-V0 for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 17:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36258) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMfof-0000QN-S0 for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 17:34:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMfof-0005nZ-KW for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 17:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: mituharu@math.s.chiba-u.ac.jp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 21:34:01 +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.155691918922229 (code B ref 35468); Fri, 03 May 2019 21:34:01 +0000 Original-Received: (at 35468) by debbugs.gnu.org; 3 May 2019 21:33:09 +0000 Original-Received: from localhost ([127.0.0.1]:49801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMfno-0005mT-Vx for submit@debbugs.gnu.org; Fri, 03 May 2019 17:33:09 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:61735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMfnm-0005mH-A4 for 35468@debbugs.gnu.org; Fri, 03 May 2019 17:33:07 -0400 Original-Received: from weber.math.s.chiba-u.ac.jp (weber [192.168.32.4]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 38CA3F08E1; Sat, 4 May 2019 06:33:00 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) Original-Received: from 180.3.209.86 (SquirrelMail authenticated user mituharu) by weber.math.s.chiba-u.ac.jp with HTTP; Sat, 4 May 2019 06:33:05 +0900 In-Reply-To: <877eb7l5vl.fsf@gmail.com> X-Priority: 3 (Normal) Importance: Normal 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:158726 Archived-At: > mituharu@math.s.chiba-u.ac.jp writes: > >> Unlike the NS port, the terminal code in the Mac port is much like the >> X11 >> version. > > I looked at your code and fortunately it indeed looks like the same > abstractions for glyph drawing that would work for the X11 version would > work for the Mac port. I deliberately made the Mac port code aligned to the X11 version for the consistency in behavior as well as the ease of catching up upstream changes. > Why does it use the background color of GC? It appears that the > Cairo version uses the foreground color of GC; is that because the Cairo > version doesn't handle stippling? I wrote both Mac and cairo versions, and I used the foreground color for cairo (although I already used the background color on the Mac port) to minimize the changes from the Xlib version because it was incorporated into xterm.c. Actually the stipple bitmap support for the Mac port was added very recently. It had been missing in the Mac port for more than a decade because I also thought it is an outdated thing and not worth implemented. But I changed my mind by looking at an unexpected use of stipple bitmaps: https://lists.gnu.org/r/emacs-devel/2019-03/msg00502.html So the use of the background color of GC on the Mac port is not for stipple bitmaps (at least historically) but mainly for the following reasons: 1. It can avoid XGetGCValues dance you mentioned without the drastic changes in the code that may make catching up mainstream difficult. 2. There are multiple cases that "filling with the background color" is useful. 3. The Mac port supports "vibrancy" (a frosted-glass-like translucency effect) only for the background color. So filling with the background color is implemented differently from doing that with the foreground color on the Mac port (see the macro CG_CONTEXT_FILL_RECT_WITH_GC_BACKGROUND in macterm.h). It is regarded as "special stipples" and actually controlled by the stipple attibute of faces: https://bitbucket.org/mituharu/emacs-mac/src/df827786d7a7fb0a0e2f27577af67e32d9a888a9/doc/emacs/macport.texi#lines-519 In retrospect, it is natural to associate "stipple" operations with "erasing" (filling with the background color) in this sense. >> I guess introducing the erase_rectagle handler makes things simpler and >> efficient. > > Looking over the code, and considering that stippling is quite uncommon > nowadays (GTK 3 removed it, AFAIK), I think the best approach would be > to define 3 separate interface procedures: > > 1) fill_rectangle: handles x_fill_rectangle/mac_fill_rectangle > > 2) fill_rectangle_with_color: handles (1), but also with the temporary > overriding of the GC that's done frequently for mac_erase_rectangle. > > 3) fill_rectangle_with_stipple: handles the temporary XFillStyle > overriding of the GC. > > A third procedure wouldn't be inelegant in comparison to the > alternatives, since otherwise I would need a set_context_stipple > procedure to indicate stippling. > > Then mac_fill_rectangle can be assigned to fill_rectangle, and > mac_erase_rectangle can be assigned to fill_rectangle_with_stipple. Because of the reasons I mentioned above, I'd prefer erase_rectangle to fill_rectangle_with_color/stipple. Also, many use cases in the Mac port involve erasure of multiple rectangles, so erase_rectangles (multi-rectangle version like XFillRectangles) would eliminate some overhead of setting up colors and the clipping area. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp