unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: Status of MAC/W32/X consolidation -- first major patch committed.
Date: 17 Mar 2003 12:40:04 +0100	[thread overview]
Message-ID: <5xsmtmp6gb.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <m2vfyiwevr.fsf@nyaumo.jasonr.f2s.com>

Jason Rumney <jasonr@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I swapped the names of "w32_get_glyph_overhangs" and
> > "x_get_glyph_overhangs" to make the X and W32 code less different...
> 
> That could be dangerous. 

I agree in general, but not in this case... read on.


>                          Usually if I changed the x_ prefix to w32_,
> I did so because the interface or effect of the function was
> different. In this case, the interface was as follows.
> 
> static void w32_get_glyph_overhangs P_ ((HDC hdc, struct glyph *,
>                                           struct frame *,
>                                           int *, int *));



Yes, I understand that.  However, in this specific case, I really
didn't see any reason for a w32-specific version, as the change to
the interface (adding `hdc' arg) seemed unnecessary -- as the function
didn't reference `hdc' at all.  Here is the original version:

static void
w32_get_glyph_overhangs (hdc, glyph, f, left, right)
     HDC hdc;
     struct glyph *glyph;
     struct frame *f;
     int *left, *right;
{
  *left = *right = 0;

  if (glyph->type == CHAR_GLYPH)
    {
      XFontStruct *font;
      struct face *face;
      wchar_t char2b;
      XCharStruct *pcm;

      face = x_get_glyph_face_and_encoding (f, glyph, &char2b, NULL);
      font = face->font;

      if (font
          && (pcm = w32_per_char_metric (font, &char2b,
                                         glyph->w32_font_type)))
	{
	  if (pcm->rbearing > pcm->width)
	    *right = pcm->rbearing - pcm->width;
	  if (pcm->lbearing < 0)
	    *left = -pcm->lbearing;
	}
    }
}

> 
>  x_get_glyph_overhangs was probably a wrapper to present the same
>  interface as the x equivalent, but less efficient due to needing to
>  get the hdc on every call (it is called for every glyph displayed, so
>  that makes a big difference).
> 

Again, since the original w32_get_glyph_overhangs didn't actually
reference the hdc argument, but the original x_get_glyph_overhangs
(and the new w32_get_glyph_overhangs) still did the extra work of
getting the hdc, I thought that it might be required to do so
due to side-effects of the get_frame_dc.

So I believe my changes are safe!

We may further simplify the code by getting rid of the new
w32_get_glyph_overhangs (if the assumption about required side-effects
is false).  Then just discard w32_get_glyph_overhangs and use
x_get_glyph_overhangs directly in its place.


BTW, this leads me to another strange thing about the merged version
of this code (based on the code from xterm.c):

void
x_get_glyph_overhangs (glyph, f, left, right)
     struct glyph *glyph;
     struct frame *f;
     int *left, *right;
{
  *left = *right = 0;

  if (glyph->type == CHAR_GLYPH)
    {
      XFontStruct *font;
      struct face *face;
      struct font_info *font_info;
      XChar2b char2b;
      XCharStruct *pcm;

      face = get_glyph_face_and_encoding (f, glyph, &char2b, NULL);
      font = face->font;
      font_info = FONT_INFO_FROM_ID (f, face->font_info_id);
      if (font  /* ++KFS: Should this be font_info ?  */
	  && (pcm = rif->per_char_metric (font, &char2b, glyph->font_type)))
	{
	  if (pcm->rbearing > pcm->width)
	    *right = pcm->rbearing - pcm->width;
	  if (pcm->lbearing < 0)
	    *left = -pcm->lbearing;
	}
    }
}


Notice that the code finds the `font_info' for the font, but doesn't actually
use that for anything.  I have a suspicion that the test that reads
        if (font && ...)
was really meant to read
        if (font_info && ...)

I see three indications why this may be true:
1) Why find the font_info (and not using it) ?
2) Is font (== face->font) ever NULL ?  (sounds strange to me)
3) Other similar parts of the code which call per_char_metric
   actually check the font_info rather than the font.

If anyone can sched some light on this, it would be appreciated!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

  reply	other threads:[~2003-03-17 11:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-10 12:13 Status of MAC/W32/X consolidation and some questions Kim F. Storm
2003-03-10 17:00 ` Andrew Choi
2003-03-11  1:06   ` Kim F. Storm
2003-03-11 15:31     ` Andrew Choi
2003-03-10 17:09 ` Andrew Choi
2003-03-11  1:04   ` Kim F. Storm
2003-03-11 15:40     ` Andrew Choi
2003-03-10 17:23 ` Benjamin Riefenstahl
2003-03-11  1:01   ` Kim F. Storm
2003-03-11  0:19     ` Juanma Barranquero
2003-03-11 10:35       ` Kim F. Storm
2003-03-11 10:07     ` Jason Rumney
2003-03-11 11:09       ` Kim F. Storm
2003-03-12  4:47       ` Miles Bader
2003-03-11  0:03 ` Jason Rumney
2003-03-11  1:47 ` Miles Bader
2003-03-11 19:03   ` Stefan Monnier
2003-03-12  4:44     ` Miles Bader
2004-07-22 15:11   ` Kim F. Storm
2004-07-22 21:40     ` Miles Bader
2003-03-11 14:19 ` Kim F. Storm
2003-03-12 19:27   ` Eli Zaretskii
2003-03-12 23:01     ` Kim F. Storm
2003-03-16 22:00   ` Status of MAC/W32/X consolidation -- first major patch committed Kim F. Storm
2003-03-16 22:27     ` Jason Rumney
2003-03-16 23:59       ` Kim F. Storm
2003-03-17  8:56         ` Jason Rumney
2003-03-17 11:40           ` Kim F. Storm [this message]
2003-03-17 14:56     ` Benjamin Riefenstahl
     [not found]       ` <1047913554.3e75e4529bc88@webmail.freedom2surf.net>
2003-03-17 16:43         ` Benjamin Riefenstahl
2003-03-17 19:01       ` Juanma Barranquero
2003-03-21 15:10     ` Status of MAC/W32/X consolidation -- second " Kim F. Storm
2003-03-21 16:46       ` Juanma Barranquero
2003-03-21 22:48         ` Kim F. Storm
2003-03-24 20:07       ` Andrew Choi
2003-03-31 22:16       ` Status of MAC/W32/X consolidation -- third " Kim F. Storm
2003-04-01  1:13         ` Andrew Choi
2003-04-01  9:27           ` Kim F. Storm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5xsmtmp6gb.fsf@kfs2.cua.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).