Re: font-backend mechanism on Windows and Mac?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 14 Sep 2007 09:52:23 -0400, "Adrian Robert" <address@hidden> 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
                                address@hidden