From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32 Date: Thu, 02 May 2019 23:14:55 +0300 Message-ID: <83o94kobpc.fsf@gnu.org> 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> <83zho6ox5u.fsf@gnu.org> <878svomynv.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103813"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35468@debbugs.gnu.org To: Alex Gramiak Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 02 22:16:13 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 1hMI7p-000QrW-1a for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 22:16:13 +0200 Original-Received: from localhost ([127.0.0.1]:58106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMI7o-00013N-1C for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 16:16:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMI7g-000137-BQ for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:16:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMI7f-0004Co-57 for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:16:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33549) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMI7e-0004CV-UJ for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMI7e-0007MV-HT for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 20:16: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.155682812928245 (code B ref 35468); Thu, 02 May 2019 20:16:02 +0000 Original-Received: (at 35468) by debbugs.gnu.org; 2 May 2019 20:15:29 +0000 Original-Received: from localhost ([127.0.0.1]:47093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMI77-0007LU-37 for submit@debbugs.gnu.org; Thu, 02 May 2019 16:15:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMI73-0007LF-2U for 35468@debbugs.gnu.org; Thu, 02 May 2019 16:15:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMI6w-0002zB-4k; Thu, 02 May 2019 16:15:19 -0400 Original-Received: from [176.228.60.248] (port=4181 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMI6v-0004vj-3R; Thu, 02 May 2019 16:15:17 -0400 In-reply-to: <878svomynv.fsf@gmail.com> (message from Alex Gramiak on Thu, 02 May 2019 13:41:56 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:158663 Archived-At: > From: Alex Gramiak > Cc: 35468@debbugs.gnu.org > Date: Thu, 02 May 2019 13:41:56 -0600 It's late down here, and I had a bad week and an even worse day. So just a few quick answers for now, and the rest will follow in a few hours. > > It is slightly inelegant, but it certainly isn't a catastrophe. > > Unused arguments that are there for the sake of a function signature > > compatibility is not an uncommon technique in C. > > I suppose. It's only because of the w32 version that uses s->HDC that > `s' needs to be passed in at all for the glyph string version. Why can't you pass HDC itself? It's just a pointer. > > But please note that gc->foreground and background used in some cases > > are exactly the color numbers used directly in other cases, so I think > > you could always pass colors or always pass a GC. > > Do you mean that I could leave out either the color or the GC argument? Yes, that was my impression from looking at the code. We will just need to pack the color into a GC in some cases. > >> 4) The w32 versions of some procedures need to save the font around the > >> calls to font->driver->draw; is this necessary? > > > > Yes. The X 'draw' methods accept the font as an argument, but the w32 > > implementation relies on setting the font outside of the 'draw' method > > because the 'draw' method draws using the "currently selected font". > > Then we need to restore the original font. > > Where do the X 'draw' methods accept the font as an argument? Looking > at, e.g., *_draw_glyph_string_foreground, font->driver->draw takes the > same arguments. Look at the driver's 'draw' method itself, e.g. xftfont_draw. > Since font->driver->draw takes in the glyph string, why can't the 'draw' > methods use SelectObject (s->hdc, FONT_HANDLER (s->font)) and > SelectObject (s->hdc, old_font)? It could, but that would be less efficient, since we many times call the draw method several times in a row. > If they can't, is there any other way to do it inside the draw methods? > It seems like it would simplify the code on the w32 side and make it > more in line with the other backends. I would leave this for another rainy day, and for now just have an interface which just w32 will implement. > > You could define a set_font interface, with only a w32 implementation. > > Did you have something else in mind besides the > save/restore_secondary_context_font I posted? Not besides, instead. > >> if (gdif->save_secondary_context_font) > > > > This name is misleading: this is not a "secondary" font. We are > > selecting the font to be used for drawing by the font driver's 'draw' > > method. > > The "secondary" here applies to "context", not "context font". I used > the name since the code changes s->hdc's (what I dubbed to be the > "secondary context") font. Would you prefer just > {save,restore}_context_font? There's no context here, either. That call selects a different font, and returns a handle of the previous font so that it could be restored later. Stay tuned for the rest. Thanks.