font-backend mechanism on Windows and Mac?

font-backend mechanism on Windows and Mac?

[Kenichi Handa]

Could someone please let me know about the current status of
font-backend mechanism on Windows and Mac?

Has it already been implemented and working well?  If so,
I'd like to go ahead and delete old font handling codes,
improve fontset related code so that it works better with
the font backend mechanism.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 10 Sep 2007 11:39:39 +0900, Kenichi Handa <handa@m17n.org> said:

> Could someone please let me know about the current status of
> font-backend mechanism on Windows and Mac?

> Has it already been implemented and working well?  If so, I'd like
> to go ahead and delete old font handling codes, improve fontset
> related code so that it works better with the font backend
> mechanism.

AFAIK, no work has been done for the Mac Carbon port.  But that should
not prevent the unicode-2 branch from going forward; the Carbon port
in the trunk is already not functioning after the multi-tty merge, and
might be replaced with the Cocoa/GNUstep port that has font-backend
support.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <wlejh7md9y.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Mon, 10 Sep 2007 11:39:39 +0900, Kenichi Handa <handa@m17n.org> said:
> > Could someone please let me know about the current status of
> > font-backend mechanism on Windows and Mac?

> > Has it already been implemented and working well?  If so, I'd like
> > to go ahead and delete old font handling codes, improve fontset
> > related code so that it works better with the font backend
> > mechanism.

> AFAIK, no work has been done for the Mac Carbon port.  But that should
> not prevent the unicode-2 branch from going forward; the Carbon port
> in the trunk is already not functioning after the multi-tty merge, and
> might be replaced with the Cocoa/GNUstep port that has font-backend
> support.

Where is the code of Cocoa/GNUstep port?  I've just grepped
'include "font.h"' but the result is as below (no
mac-specific file includes it).

font.c:38:#include "font.h"
fontset.c:60:#include "font.h"
frame.c:57:#include "font.h"
ftfont.c:41:#include "font.h"
ftxfont.c:36:#include "font.h"
w32fns.c:62:#include "font.h"
w32font.c:31:#include "font.h"
w32term.c:64:#include "font.h"
xdisp.c:207:#include "font.h"
xfaces.c:251:#include "font.h"
xfns.c:53:#include "font.h"
xfont.c:36:#include "font.h"
xftfont.c:37:#include "font.h"
xterm.c:106:#include "font.h"

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 10 Sep 2007 12:12:01 +0900, Kenichi Handa <handa@m17n.org> said:

> Where is the code of Cocoa/GNUstep port?

It's available from http://emacs-app.sourceforge.net/.  The latest one
(9.0-rc1), which is downloadable from (*1), is a bit old (released in
last December), but the author said the next release was being
prepared (*2).

(*1) http://sourceforge.net/project/showfiles.php?group_id=148174
(*2) http://sourceforge.net/mailarchive/message.php?msg_name=55f7df060708241239q118b13h692ff6c4cd5d778%40mail.gmail.com

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <wl4pi3b2rs.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Mon, 10 Sep 2007 12:12:01 +0900, Kenichi Handa <handa@m17n.org> said:
> > Where is the code of Cocoa/GNUstep port?

> It's available from http://emacs-app.sourceforge.net/.  The latest one
> (9.0-rc1), which is downloadable from (*1), is a bit old (released in
> last December), but the author said the next release was being
> prepared (*2).

> (*1) http://sourceforge.net/project/showfiles.php?group_id=148174
> (*2) http://sourceforge.net/mailarchive/message.php?msg_name=55f7df060708241239q118b13h692ff6c4cd5d778%40mail.gmail.com

Adrian, is your change ready for committing to the Emacs CVS
resitory?

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/10/07, Kenichi Handa <handa@m17n.org> wrote:
> In article <wl4pi3b2rs.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
> >>>>>> On Mon, 10 Sep 2007 12:12:01 +0900, Kenichi Handa <handa@m17n.org> said:
> > > Where is the code of Cocoa/GNUstep port?
>
> > It's available from http://emacs-app.sourceforge.net/.  The latest one
> > (9.0-rc1), which is downloadable from (*1), is a bit old (released in
> > last December), but the author said the next release was being
> > prepared (*2).
>
> > (*1) http://sourceforge.net/project/showfiles.php?group_id=148174
> > (*2) http://sourceforge.net/mailarchive/message.php?msg_name=55f7df060708241239q118b13h692ff6c4cd5d778%40mail.gmail.com
>
> Adrian, is your change ready for committing to the Emacs CVS
> resitory?


I'm going to release rc2 today or tomorrow, which will complete the
update of the port to unicode-2.  Depending on reported issues, I
think it would soon be ready for committing, depending if people
decide to allow it.

BUT, I have not tried it with the new multi-tty changes that made it
into the branch a week or two ago.  I'll look at the effects of this
after the release.

Regarding the font backend question, FWIW, I have already deleted the
Cocoa port's old font handling code.  I also suspect the Carbon/AppKit
port could use most of what is in nsfont.m, changing out my uses of
CoreGraphics in draw() for existing Carbon code.

-Adrian

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <55f7df060709100539o41c6fdb2w72d909199371fa1f@mail.gmail.com>, "Adrian Robert" <adrian.b.robert@gmail.com> writes:

> I'm going to release rc2 today or tomorrow, which will complete the
> update of the port to unicode-2.

Thank you for the good news.

> Depending on reported issues, I
> think it would soon be ready for committing, depending if people
> decide to allow it.

Have you already sent the assignment paper to FSF?

> BUT, I have not tried it with the new multi-tty changes that made it
> into the branch a week or two ago.  I'll look at the effects of this
> after the release.

I haven't checked the new facility of multi-tty with
emacs-unicode-2 either.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/10/07, Kenichi Handa <handa@m17n.org> wrote:
> In article <55f7df060709100539o41c6fdb2w72d909199371fa1f@mail.gmail.com>, "Adrian Robert" <adrian.b.robert@gmail.com> writes:
>
> > I'm going to release rc2 today or tomorrow, which will complete the
> > update of the port to unicode-2.
>
> Thank you for the good news.
>
> > Depending on reported issues, I
> > think it would soon be ready for committing, depending if people
> > decide to allow it.
>
> Have you already sent the assignment paper to FSF?

Yes, though this is not the main issue, but whether a contribution of
this size that would need to be maintained in the future, and provides
partially overlapping functionality with the existing Carbon port,
would be accepted.  Some on the list have posted in favor, and none
have really objected, but that may be because a lot of people don't
care at the moment, but might if the code were actually going to go
in.  Though it won't interfere with other ports, aside from the
presence of a few ifdefs in common files.

Anyway, the new release is at http://emacs-app.sf.net/


-Adrian

Re: font-backend mechanism on Windows and Mac?

[Stefan Monnier]

>> > I'm going to release rc2 today or tomorrow, which will complete the
>> > update of the port to unicode-2.
>> 
>> Thank you for the good news.
>> 
>> > Depending on reported issues, I
>> > think it would soon be ready for committing, depending if people
>> > decide to allow it.
>> 
>> Have you already sent the assignment paper to FSF?

> Yes, though this is not the main issue, but whether a contribution of
> this size that would need to be maintained in the future, and provides
> partially overlapping functionality with the existing Carbon port,
> would be accepted.  Some on the list have posted in favor, and none
> have really objected, but that may be because a lot of people don't
> care at the moment, but might if the code were actually going to go
> in.  Though it won't interfere with other ports, aside from the
> presence of a few ifdefs in common files.

> Anyway, the new release is at http://emacs-app.sf.net/

I'm not very interested in replacing Carbon with Cocoa under Mac OS X, but
the fact that it adds support for GNUstep makes it a lot more attractive.

I do hope that it's somewhat limited to the redisplay and that the rest of
the Carbon-Emacs effort (unrelated to UI) will be preserved.  But to tell
you the truth, I do not know what that amounts to, so for all I know,
there's nothing left to preserve there.


        Stefan

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/11/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I do hope that it's somewhat limited to the redisplay and that the rest of
> the Carbon-Emacs effort (unrelated to UI) will be preserved.  But to tell
> you the truth, I do not know what that amounts to, so for all I know,
> there's nothing left to preserve there.

The Cocoa and Carbon ports share about as much code as any other pair,
e.g. X11 and W32.  It would be like if the GTK port and the X11 port
were first created independently without using either of each others'
code.  Except that, additionally, the Cocoa port (higher level, like
GTK) cannot use the Carbon port's code even if it wants to now,
because these APIs are not available under GNUstep.

In the reverse direction, I'm not sure whether Carbon-Appkit was able
to take much from the Cocoa port, or if the constraints of its own
architecture made this impractical.

There's not much code in the ports that's NOT related to UI, which is
the way it should be (*), but where there is, e.g. Andrew Choi's Mac
unexec module, the Cocoa port uses it.

(*) Generally a lot of code is shared between all ports.  E.g. X11,
Carbon, and Cocoa all use the same code for parsing lisp menus into
widget_value structures.  I split this into nsmenu_common.c (1000
lines), but did not modify xmenu.c or macmenu.c to use it.  There's a
line between refactoring of this kind that simplifies maintenance
(less understanding of emacs internals needed by window system coders,
less identical code in multiple files to keep in sync) and that makes
things too inflexible for some ports to easily work with, but IMHO
there's a lot more that could be done.  Though in a large project like
this, it's not easy.


-Adrian

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> Could someone please let me know about the current status of
> font-backend mechanism on Windows and Mac?
>   

It has been implemented on Windows, and is working with one very obvious
bug when anti-aliasing is enabled - the background is not erased often
enough, leading to overstrike effects when redisplay occurs.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46E4F571.3030101@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > Could someone please let me know about the current status of
> > font-backend mechanism on Windows and Mac?
> >   

> It has been implemented on Windows, and is working with one very obvious
> bug when anti-aliasing is enabled - the background is not erased often
> enough, leading to overstrike effects when redisplay occurs.


I've just installed the latest emacs-unicode-2 code on
Windows XP with --enable-font-backend.  Do you have a recipe
for reproducing the problem above?

By the way, one strange thing is that all Japanese
characters are displayed by 90-degree turned.  C-u C-x =
tells that the font "@ms ui gothic" is used.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> In article <46E4F571.3030101@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
>
>   
>> Kenichi Handa wrote:
>>     
>>> Could someone please let me know about the current status of
>>> font-backend mechanism on Windows and Mac?
>>>   
>>>       
>
>   
>> It has been implemented on Windows, and is working with one very obvious
>> bug when anti-aliasing is enabled - the background is not erased often
>> enough, leading to overstrike effects when redisplay occurs.
>>     
>
>
> I've just installed the latest emacs-unicode-2 code on
> Windows XP with --enable-font-backend.  Do you have a recipe
> for reproducing the problem above?
>   

Right click on the Windows desktop and select "Properties" (last menu
entry) from the popup menu. On the "Appearance" tab (3rd of 4 tabs),
click the "Effects..." button (top button in lower right corner). The
second option in the dialog that appears contains a tickbox to enable
antialiasing, and a dropdown selection for the method to use. I have
mine set to "Cleartype", I'm not sure if the problem also appears with
"Standard" anti-aliasing. Emacs may need to be restarted after changing
this setting.


> By the way, one strange thing is that all Japanese
> characters are displayed by 90-degree turned.  C-u C-x =
> tells that the font "@ms ui gothic" is used.
>   

That would be one more bug then. The old font selection code used to
explicitly filter out fonts beginning with @ for that reason.

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Jason Rumney wrote:
> Right click on the Windows desktop and select "Properties" (last menu
> entry) from the popup menu. On the "Appearance" tab (3rd of 4 tabs),
> click the "Effects..." button (top button in lower right corner). The
> second option in the dialog that appears contains a tickbox to enable
> antialiasing, and a dropdown selection for the method to use. I have
> mine set to "Cleartype", I'm not sure if the problem also appears with
> "Standard" anti-aliasing. Emacs may need to be restarted after changing
> this setting.
>   

I should have mentioned that the easiest way to see the problem is to
open another window that is smaller than the Emacs frame, and drag it so
it partially covers the frame, then drag it off again.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46E54B7B.3070104@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Jason Rumney wrote:
> > Right click on the Windows desktop and select "Properties" (last menu
> > entry) from the popup menu. On the "Appearance" tab (3rd of 4 tabs),
> > click the "Effects..." button (top button in lower right corner). The
> > second option in the dialog that appears contains a tickbox to enable
> > antialiasing, and a dropdown selection for the method to use. I have
> > mine set to "Cleartype", I'm not sure if the problem also appears with
> > "Standard" anti-aliasing. Emacs may need to be restarted after changing
> > this setting.
> >   

> I should have mentioned that the easiest way to see the problem is to
> open another window that is smaller than the Emacs frame, and drag it so
> it partially covers the frame, then drag it off again.

I confirmed that bug, and found that the problem is not
specific to Windows port.  As there were comments paying
attention to anti-aliased drawing in xdisp.c, I didn't
change code for handling overlapping when I committed
font-backend codes, but I just found that there is a
fundamental bug.  I'm now investigating how to fix it.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <E1IVLwZ-00028a-AP@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> I confirmed that bug, and found that the problem is not
> specific to Windows port.  As there were comments paying
> attention to anti-aliased drawing in xdisp.c, I didn't
> change code for handling overlapping when I committed
> font-backend codes, but I just found that there is a
> fundamental bug.  I'm now investigating how to fix it.

I've just installed fixes for X Window.  Could you please
fix w32term.c and w32font.c by the same way as done in
xterm.c and xftfont.c (the diffs are attached)?

Adrian, I think your Cocoa port needs the similar fix,
doesn't it?

---
Kenichi Handa
handa@m17n.org

Index: xterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.804.2.91
retrieving revision 1.804.2.92
diff -u -r1.804.2.91 -r1.804.2.92
--- xterm.c	21 Aug 2007 04:53:43 -0000	1.804.2.91
+++ xterm.c	13 Sep 2007 11:02:20 -0000	1.804.2.92
@@ -1228,13 +1228,18 @@
 x_set_glyph_string_clipping (s)
      struct glyph_string *s;
 {
-  XRectangle r;
-  get_glyph_string_clip_rect (s, &r);
-  XSetClipRectangles (s->display, s->gc, 0, 0, &r, 1, Unsorted);
 #ifdef USE_FONT_BACKEND
-  s->clip_x = r.x, s->clip_y = r.y;
-  s->clip_width = r.width, s->clip_height = r.height;
-#endif	/* USE_FONT_BACKEND */
+  XRectangle *r = s->clip;
+#else
+  XRectangle r[2];
+#endif
+  int n = get_glyph_string_clip_rects (s, r, 2);
+
+  if (n > 0)
+    XSetClipRectangles (s->display, s->gc, 0, 0, r, n, Unsorted);
+#ifdef USE_FONT_BACKEND
+  s->num_clips = n;
+#endif
 }
 
 
@@ -1251,10 +1256,12 @@
 #ifdef USE_FONT_BACKEND
   if (enable_font_backend)
     {
-      r.x = dst->clip_x = src->x;
-      r.width = dst->clip_width = src->width;
-      r.y = dst->clip_y = src->y;
-      r.height = dst->clip_height = src->height;
+      r.x = src->x;
+      r.width = src->width;
+      r.y = src->y;
+      r.height = src->height;
+      dst->clip[0] = r;
+      dst->num_clips = 1;
     }
   else
     {
@@ -2839,7 +2846,7 @@
 	    x_set_glyph_string_clipping (next);
 	    x_draw_glyph_string_background (next, 1);
 #ifdef USE_FONT_BACKEND
-	    next->clip_width = 0;
+	    next->num_clips = 0;
 #endif	/* USE_FONT_BACKEND */
 	  }
     }
@@ -3028,7 +3035,7 @@
 		XSetClipMask (prev->display, prev->gc, None);
 		prev->hl = save;
 #ifdef USE_FONT_BACKEND
-		prev->clip_width = 0;
+		prev->num_clips = 0;
 #endif	/* USE_FONT_BACKEND */
 	      }
 	}
@@ -3055,7 +3062,7 @@
 		XSetClipMask (next->display, next->gc, None);
 		next->hl = save;
 #ifdef USE_FONT_BACKEND
-		next->clip_width = 0;
+		next->num_clips = 0;
 #endif	/* USE_FONT_BACKEND */
 	      }
 	}
@@ -3064,7 +3071,7 @@
   /* Reset clipping.  */
   XSetClipMask (s->display, s->gc, None);
 #ifdef USE_FONT_BACKEND
-  s->clip_width = 0;
+  s->num_clips = 0;
 #endif	/* USE_FONT_BACKEND */
 }
 
Index: xftfont.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/Attic/xftfont.c,v
retrieving revision 1.1.2.19
retrieving revision 1.1.2.20
diff -u -r1.1.2.19 -r1.1.2.20
--- xftfont.c	22 Aug 2007 12:34:29 -0000	1.1.2.19
+++ xftfont.c	13 Sep 2007 11:04:11 -0000	1.1.2.20
@@ -512,12 +512,11 @@
 			      FRAME_X_WINDOW (f),
 			      FRAME_X_VISUAL (f),
 			      FRAME_X_COLORMAP (f));
-  if (s->clip_width)
-    {
-      r.x = s->clip_x, r.width = s->clip_width;
-      r.y = s->clip_y, r.height = s->clip_height;
-      XftDrawSetClipRectangles (xft_draw, 0, 0, &r, 1);
-    }
+  if (s->num_clips > 0)
+    XftDrawSetClipRectangles (xft_draw, 0, 0, s->clip, s->num_clips);
+  else
+    XftDrawSetClip (xft_draw, NULL);
+
   if (with_background)
     {
       struct font *font = (struct font *) face->font_info;
@@ -532,8 +531,6 @@
 
   XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont,
 		 x, y, code, len);
-  if (s->clip_width)
-    XftDrawSetClip (xft_draw, NULL);
   if (s->font_info != face->font_info)
     XftDrawDestroy (xft_draw);
   UNBLOCK_INPUT;

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> I've just installed fixes for X Window.  Could you please
> fix w32term.c and w32font.c by the same way as done in
> xterm.c and xftfont.c (the diffs are attached)?
>   

I've done that, now the only problems are the font problem you found,
and the performance seems much worse than the old code (redisplay after
moving a window over Emacs now takes around 2 seconds while in trunk it
is imperceptible), but that will only be fixed by getting more eyes
looking at the code.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46E93E1C.3030808@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > I've just installed fixes for X Window.  Could you please
> > fix w32term.c and w32font.c by the same way as done in
> > xterm.c and xftfont.c (the diffs are attached)?

> I've done that, now the only problems are the font problem you found,
> and the performance seems much worse than the old code (redisplay after
> moving a window over Emacs now takes around 2 seconds while in trunk it
> is imperceptible), but that will only be fixed by getting more eyes
> looking at the code.

Do you mean that the displaying got slower after the recent
change?

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> Do you mean that the displaying got slower after the recent
> change?
>   

Perhaps, it does seem a little slower, and the more complex clipping
masks might have caused that, but I think most of the slowness is from
the new font-backend itself. It seems to be outputting a character at a
time, rather than whole lines. It might be due to a workaround in the
Windows code to avoid a Cleartype bug in the old font code (though I'd
expect the old code to be similarly slow in that case), or it might be
not combining multiple redraw requests as the overlapping window is
moved over the Emacs frame.

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/14/07, Jason Rumney <jasonr@gnu.org> wrote:
> Kenichi Handa wrote:
> > Do you mean that the displaying got slower after the recent
> > change?
> >
>
> Perhaps, it does seem a little slower, and the more complex clipping
> masks might have caused that, but I think most of the slowness is from
> the new font-backend itself. It seems to be outputting a character at a
> time, rather than whole lines. It might be due to a workaround in the
> Windows code to avoid a Cleartype bug in the old font code (though I'd
> expect the old code to be similarly slow in that case), or it might be
> not combining multiple redraw requests as the overlapping window is
> moved over the Emacs frame.

Another possibility is the metrics implementation.  In text_extents()
the W32 and Xft impls query the font itself for the metrics every
time.  With Xft this may be fast if the font is client-side (and it
does it for the whole string, not each char), but possibly under
Windows it is not.  In Cocoa nsfont.m metrics are cached in blocks of
256 chars to deal with this.  It would be easy to adapt that to other
terms, though then the code should perhaps go as a utility into
font.c.  (But drivers _should_ do a full-string determination like
xftfont.c does if they can, so they wouldn't need it.)

How is the performance under X without Xft?

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Adrian Robert wrote:
> Another possibility is the metrics implementation.  In text_extents()
> the W32 and Xft impls query the font itself for the metrics every
> time.  With Xft this may be fast if the font is client-side (and it
> does it for the whole string, not each char), but possibly under
> Windows it is not.  In Cocoa nsfont.m metrics are cached in blocks of
> 256 chars to deal with this.
This might make a difference, the old Windows code used to cache the
metrics of ASCII characters for each font.

> font.c.  (But drivers _should_ do a full-string determination like
> xftfont.c does if they can, so they wouldn't need it.)
>   
I think the lack of comments for the font backend has led us to
implement this incorrectly.
Actually, when text_extents is called with a metrics argument, nglyphs
is always 1, so there is no need to loop over all the characters, and
there is only one metric to fill in, not an array of them. In the case
where metrics is NULL, the Windows version does do a full string
determination, but it has to convert the unsigned array of characters to
a short array for the Windows API functions.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46EB1FB5.40603@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Adrian Robert wrote:
> > Another possibility is the metrics implementation.  In text_extents()
> > the W32 and Xft impls query the font itself for the metrics every
> > time.  With Xft this may be fast if the font is client-side (and it
> > does it for the whole string, not each char), but possibly under
> > Windows it is not.  In Cocoa nsfont.m metrics are cached in blocks of
> > 256 chars to deal with this.
> This might make a difference, the old Windows code used to cache the
> metrics of ASCII characters for each font.

> > font.c.  (But drivers _should_ do a full-string determination like
> > xftfont.c does if they can, so they wouldn't need it.)
> >   
> I think the lack of comments for the font backend has led us to
> implement this incorrectly.

Which part of comment do you mean?

> Actually, when text_extents is called with a metrics argument, nglyphs
> is always 1, so there is no need to loop over all the characters, and
> there is only one metric to fill in, not an array of them.

In most cases, text_extents is called for one glyph by one.
That is because the original display engine calls
x_produce_glyphs for one character by one.  To improve it,
we will need a very big change in the core part of the
display engine.

But, x_compute_glyph_string_overhangs will call text_extents
with multiple glyphs.

> In the case
> where metrics is NULL, the Windows version does do a full string
> determination, but it has to convert the unsigned array of characters to
> a short array for the Windows API functions.

??? text_extents should always be called with non-NULL
metrics arg.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> In article <46EB1FB5.40603@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
>
> Which part of comment do you mean?
>   

  /* Perform the size computation of glyphs of FONT and fillin members
     of METRICS.  The glyphs are specified by their glyph codes in
     CODE (length NGLYPHS).  */

It is clear from that comment that multiple glyphs can be passed to that
function, but it is not clear that metrics is a single struct. I
originally implemented it as if metrics was an array of length nglyphs,
but the implementation in xftfont.c seems to suggest a single struct.

>> In the case
>> where metrics is NULL, the Windows version does do a full string
>> determination, but it has to convert the unsigned array of characters to
>> a short array for the Windows API functions.
>>     
>
> ??? text_extents should always be called with non-NULL
> metrics arg.
>   

font.c:1948 nglyphs=1, metrics=NULL
font.c:3726 nglyphs=i, metrics=NULL

font.c:2012 nglyphs=1, metrics=&metrics
font.c:3642 nglyphs=1, metrics=&metrics

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46EB8BB4.2010500@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > In article <46EB1FB5.40603@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
> >
> > Which part of comment do you mean?
> >   

>   /* Perform the size computation of glyphs of FONT and fillin members
>      of METRICS.  The glyphs are specified by their glyph codes in
>      CODE (length NGLYPHS).  */

> It is clear from that comment that multiple glyphs can be passed to that
> function, but it is not clear that metrics is a single struct. I
> originally implemented it as if metrics was an array of length nglyphs,
> but the implementation in xftfont.c seems to suggest a single struct.

Ah, I see.  How about this?

  /* Computate the total metrics of the NGLYPHS glyphs specified by
     the font FONT and the sequence of glyph codes CODE, and store the
     result in METRICS.  */

> > ??? text_extents should always be called with non-NULL
> > metrics arg.

> font.c:1948 nglyphs=1, metrics=NULL
> font.c:3726 nglyphs=i, metrics=NULL

Ah, both of them are in experimental codes, not yet used
actually.  I have not yet decided the precise plan for them.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Kenichi Handa wrote:
> Ah, both of them are in experimental codes, not yet used
> actually.  I have not yet decided the precise plan for them.
>   

One of them must be called somewhere, because I only found the
possibility that metrics could be NULL when emacs crashed.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46ED0CFD.5090003@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > Ah, both of them are in experimental codes, not yet used
> > actually.  I have not yet decided the precise plan for them.

> One of them must be called somewhere, because I only found the
> possibility that metrics could be NULL when emacs crashed.

>> font.c:1948 nglyphs=1, metrics=NULL

This is font_drive_otf and that function is called only when
font-drive-otf or font-otf-alternates are called explicitly
from Lisp.

>> font.c:3726 nglyphs=i, metrics=NULL

This is in Fdraw_string but commented out by #if 0 and
#endif.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <46EA9371.7020701@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > Do you mean that the displaying got slower after the recent
> > change?

> Perhaps, it does seem a little slower, and the more complex clipping
> masks might have caused that, but I think most of the slowness is from
> the new font-backend itself. It seems to be outputting a character at a
> time, rather than whole lines. It might be due to a workaround in the
> Windows code to avoid a Cleartype bug in the old font code (though I'd
> expect the old code to be similarly slow in that case), or it might be
> not combining multiple redraw requests as the overlapping window is
> moved over the Emacs frame.

As I wrote before, metrics calculation is done one glyph by
one, but rendering is done for a block of glyphs (i.e. those
in one "struct glyph_string").

Anyway, while debugging the previous problem, I found that
the display engine (regardless of font-backend) does lots of
unnecessary clipping for exposing.  But, improving it
requires rather big changes.

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/13/07, Kenichi Handa <handa@m17n.org> wrote:
> In article <E1IVLwZ-00028a-AP@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>
> > I confirmed that bug, and found that the problem is not
> > specific to Windows port.  As there were comments paying
> > attention to anti-aliased drawing in xdisp.c, I didn't
> > change code for handling overlapping when I committed
> > font-backend codes, but I just found that there is a
> > fundamental bug.  I'm now investigating how to fix it.
>
> I've just installed fixes for X Window.  Could you please
> fix w32term.c and w32font.c by the same way as done in
> xterm.c and xftfont.c (the diffs are attached)?
>
> Adrian, I think your Cocoa port needs the similar fix,
> doesn't it?

I assume it does, however I can't replicate the error as described
because dragging windows from other apps over emacs does not cause
redraws under my port.  (Did I understand the symptom report
correctly?)  I guess something else causing a redraw could work:
Moving cursor over?  Dragging mouse selection over?

thanks,
Adrian

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

Adrian Robert wrote:
> I assume it does, however I can't replicate the error as described
> because dragging windows from other apps over emacs does not cause
> redraws under my port.  (Did I understand the symptom report
> correctly?)  I guess something else causing a redraw could work:
> Moving cursor over?  Dragging mouse selection over?
>   
The problem only appears after certain kinds of redraws, neither of
those produces the symptoms on Windows. Dragging the Emacs window down
until some of it is off the bottom of the screen, then dragging it back
up again produces the symptoms, but I think it goes through the same
code path, which may also not require a redraw on OSX.

Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa]

In article <55f7df060709130853q25979167p465e8e7591000ca2@mail.gmail.com>, "Adrian Robert" <adrian.b.robert@gmail.com> writes:

> I assume it does, however I can't replicate the error as described
> because dragging windows from other apps over emacs does not cause
> redraws under my port.  (Did I understand the symptom report
> correctly?)  I guess something else causing a redraw could work:
> Moving cursor over?  Dragging mouse selection over?

As far as I know, the bug is in expose_window (xdisp.c) and
what called from there.  And expose_window is triggered by
Expose or GraphicExpose events.  So, if Mac Cocoa uses
"backing store", such events doesn't happend, thus the bug
won't be revealed.  Isn't it possbile to suppress backing
streo on Cocoa?

---
Kenichi Handa
handa@m17n.org

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/13/07, Kenichi Handa <handa@m17n.org> wrote:
> In article <55f7df060709130853q25979167p465e8e7591000ca2@mail.gmail.com>, "Adrian Robert" <adrian.b.robert@gmail.com> writes:
>
> > I assume it does, however I can't replicate the error as described
> > because dragging windows from other apps over emacs does not cause
> > redraws under my port.  (Did I understand the symptom report
> > correctly?)  I guess something else causing a redraw could work:
> > Moving cursor over?  Dragging mouse selection over?
>
> As far as I know, the bug is in expose_window (xdisp.c) and
> what called from there.  And expose_window is triggered by
> Expose or GraphicExpose events.  So, if Mac Cocoa uses
> "backing store", such events doesn't happend, thus the bug
> won't be revealed.  Isn't it possbile to suppress backing
> streo on Cocoa?

It is, but because this is not used normally (not recommended under
Cocoa) rectangle expose events aren't even generated by the port, so
I'd need to add that to check.  However, looking at the patch, it
seems the change is to use multiple clip rects in some row overlap
cases.  In the Cocoa port there is a bug where the upper parts of
Tibetan text are cut off until cursor is moved over them, and it may
be related to this.  I'll try the patch as soon as I get time, next
week.

FWIW, I can't see any reason this patch would slow things down
noticeably in X, though I have not looked at the W32 code.


-Adrian

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 14 Sep 2007 09:52:23 -0400, "Adrian Robert" <adrian.b.robert@gmail.com> said:

>> As far as I know, the bug is in expose_window (xdisp.c) and what
>> called from there.

I added the multiple clip rectangles code in order for ATSUI support
on the Carbon port to work properly, and the OVERLAPS_BOTH case was
also necessary even for simple cursor movement, IIRC.

In redraw_overlapping_rows:

	  if (MATRIX_ROW_OVERLAPS_PRED_P (row)
	      && !MATRIX_ROW (w->current_matrix, i - 1)->overlapped_p)
	    overlaps |= OVERLAPS_PRED;
	  if (MATRIX_ROW_OVERLAPS_SUCC_P (row)
	      && !MATRIX_ROW (w->current_matrix, i + 1)->overlapped_p)
	    overlaps |= OVERLAPS_SUCC;

where OVERLAPS_BOTH == (OVERLAPS_PRED | OVERLAPS_SUCC).

>> And expose_window is triggered by Expose or GraphicExpose events.
>> So, if Mac Cocoa uses "backing store", such events doesn't happend,
>> thus the bug won't be revealed.  Isn't it possbile to suppress
>> backing streo on Cocoa?

> It is, but because this is not used normally (not recommended under
> Cocoa) rectangle expose events aren't even generated by the port, so
> I'd need to add that to check.

Even with backing store, calls to drawRect:, which corresponds to the
handler for expose events, occur when dragging the resize handle or
just before the animation for deiconifying.  I can observe whiteout
during such operations on the Cocoa port, but not on the Carbon+AppKit
port where the method is implemented as follows:

- (void)drawRect:(NSRect)aRect
{
  struct frame *f = [self emacsFrame];
  int x = NSMinX (aRect), y = NSMinY (aRect);
  int width = NSWidth (aRect), height = NSHeight (aRect);

  mac_clear_area (f, x, y, width, height);
  expose_frame (f, x, y, width, height);
}

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend mechanism on Windows and Mac?

[Jason Rumney]

YAMAMOTO Mitsuharu wrote:
> Even with backing store, calls to drawRect:, which corresponds to the
> handler for expose events, occur when dragging the resize handle or
> just before the animation for deiconifying.  I can observe whiteout
> during such operations on the Cocoa port, but not on the Carbon+AppKit
> port where the method is implemented as follows:
>   
This whiteout may be due to the performance problems I observed in the
new font backend, rather than the differences in implementation of
drawRect between Carbon and Cocoa ports. Or has the Carbon port been
updated to use the font backend as well?

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 14 Sep 2007 16:02:08 +0100, Jason Rumney <jasonr@gnu.org> said:

> YAMAMOTO Mitsuharu wrote:
>> Even with backing store, calls to drawRect:, which corresponds to
>> the handler for expose events, occur when dragging the resize
>> handle or just before the animation for deiconifying.  I can
>> observe whiteout during such operations on the Cocoa port, but not
>> on the Carbon+AppKit port where the method is implemented as
>> follows:

> This whiteout may be due to the performance problems I observed in
> the new font backend, rather than the differences in implementation
> of drawRect between Carbon and Cocoa ports.

Not "Carbon port" but "Carbon+AppKit port".  The method `drawRect:' is
used in the AppKit framework, which is a part of Cocoa.

I just tried changing the implementation of `drawRect:' so it calls
expose_frame, then the latter (deiconifying animation) whiteout
disappeared.  Fixing the former whiteout would need more work, but I
suspect this is not due to some performance issue: I don't find the
Cocoa port slow in drawing.

> Or has the Carbon port been updated to use the font backend as well?

I don't have a plan to do so at least until the next Mac OS X release,
which brings us a new framework for text drawing.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/14/07, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> >>>>> On Fri, 14 Sep 2007 09:52:23 -0400, "Adrian Robert" <adrian.b.robert@gmail.com> said:
>
> >> As far as I know, the bug is in expose_window (xdisp.c) and what
> >> called from there.
>
> I added the multiple clip rectangles code in order for ATSUI support
> on the Carbon port to work properly, and the OVERLAPS_BOTH case was
> also necessary even for simple cursor movement, IIRC.

OK, well I added the multi-clip code and it made zero difference to
the only problem I've seen (Tibetan script.. I'll need to investigate
that specifically).  Possibly it fixes something else I'm not seeing.
No effect on performance.



> Even with backing store, calls to drawRect:, which corresponds to the
> handler for expose events, occur when dragging the resize handle or
> just before the animation for deiconifying.  I can observe whiteout
> during such operations on the Cocoa port, but not on the Carbon+AppKit
> port where the method is implemented as follows:

Thanks, I used this and it fixed the deiconify case as you said.
Blank resize is due to NSApp going into a modal loop on resize drag,
so emacs redisplay isn't called until finished.  How did you work
around this in Carbon+AppKit?


-Adrian

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 14 Sep 2007 20:05:27 -0400, "Adrian Robert" <adrian.b.robert@gmail.com> said:

> Blank resize is due to NSApp going into a modal loop on resize drag,
> so emacs redisplay isn't called until finished.  How did you work
> around this in Carbon+AppKit?

`drawRect:' is called back automatically during the modal loop on
resize drag.  You cannot do "redisplay" that may involve Lisp
evaluation in such a window-system-level event handling context, but
"expose" is OK as it just shows the contents of the "current matrix"
that was constructed by the previous "redisplay".

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: font-backend mechanism on Windows and Mac?

[Adrian Robert]

On 9/14/07, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> >>>>> On Fri, 14 Sep 2007 20:05:27 -0400, "Adrian Robert" <adrian.b.robert@gmail.com> said:
>
> > Blank resize is due to NSApp going into a modal loop on resize drag,
> > so emacs redisplay isn't called until finished.  How did you work
> > around this in Carbon+AppKit?
>
> `drawRect:' is called back automatically during the modal loop on
> resize drag.  You cannot do "redisplay" that may involve Lisp
> evaluation in such a window-system-level event handling context, but
> "expose" is OK as it just shows the contents of the "current matrix"
> that was constructed by the previous "redisplay".

Hmm.. the effect looks a little amateurish though.  I guess it's
useful on a resize-smaller to see more or less what will be shown,
but..  it would be nice to drop out of the modal loop and track drags
manually, as with scrolling, but even subclassing NSWindow I couldn't
do it.

Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 15 Sep 2007 09:21:52 -0400, "Adrian Robert" <adrian.b.robert@gmail.com> said:

>> `drawRect:' is called back automatically during the modal loop on
>> resize drag.  You cannot do "redisplay" that may involve Lisp
>> evaluation in such a window-system-level event handling context,
>> but "expose" is OK as it just shows the contents of the "current
>> matrix" that was constructed by the previous "redisplay".

> Hmm.. the effect looks a little amateurish though.

But better than whiteout :-).

> I guess it's useful on a resize-smaller to see more or less what
> will be shown, but..  it would be nice to drop out of the modal loop
> and track drags manually, as with scrolling, but even subclassing
> NSWindow I couldn't do it.

Yes, I thought of manual (nonmodal) tracking of the resize handle,
too.  But I thought that it's too much to implement at this stage.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp