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
next prev parent 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).