Re: More enhancements to fringe bitmaps.

[storm@cua.dk (Kim F. Storm)]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On 09 Feb 2004 15:54:27 +0100, storm@cua.dk (Kim F. Storm) said:
> 
> >> Sometimes a box cursor appears as a hollow cursor in the fringe
> >> area, but I think this is not related to the above change.
> 
> > Hm, that should only happen if you have
> > cursor-in-non-selected-windows set to t.  Can you find any pattern?
> 
> Yes.  (1) Launch the Carbon Emacs, (2) M-<, C-e, and hit the space bar
> four times to move the cursor to the right fringe area of the first
> line.  (3) C-x 2 to split the window.
> 
> Just after 2), I see a hollow box cursor (should be a filled one), and
> 3) makes all cursors disappear.  I couldn't reproduce these phenomena
> on the X11 version.

Which probably makes it hard for me to reproduce -- but I'll look into it.

Is TARGET_API_MAC_CARBON defined in the setup that fails?  

If not, then x_flush is a dummy, and the display may not be updated
correctly -- just guessing...


> 
> By the way, bit-swapping in fringe.c is not needed for the mac port.
> As a matter of fact, Carbon Emacs in CVS (without the image support
> patches) has been displaying right arrows on the right fringe as left
> arrows :-)

So the following #ifdef (in fringe.c) shouldn't mention MAC_OS then?


void
init_fringe_bitmap (which, fb, once_p)
     enum fringe_bitmap_type which;
     struct fringe_bitmap *fb;
     int once_p;
{
  if (once_p || fb->dynamic)
    {
#if defined (HAVE_X_WINDOWS) || defined (MAC_OS)
      unsigned char *bits = fb->bits;
      int j;
      for (j = 0; j < fb->height; j++)
	{

> 
> Additionally, if the start address of the bitmap data for each row
> were word-aligned (by occupying 2 bytes for each row) for the mac
> port, we would not need to create intermediate data for displaying
> fringe bitmaps.  

I do see an explicit 8->16 bit conversion for W32, but not on the mac port.
Do you mean this call?

      mac_create_bitmap_from_bitmap_data (&bitmap, bits, p->wd, p->h);

Supposing that fb->bits was word aligned and 16 bits per row, what would
the code for drawing the bitmap look like then?


>                  It would be worth considering if similar things also
> happen in the w32 port.

I have been thinking about this and there's no fundamental reason why
fringe bitmaps must be 8 bits wide (except that we always guarantee
that the fringes are at least 8 bits wide if no explicit width has
been set).

The windows port uses 16 bits per row too, so it would probably be
more generic to use that on X as well; I'll think about it.

-- 
Kim F. Storm  http://www.cua.dk