Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[Kim F. Storm]

Some time ago I installed changes to support image slices, and
it works fine with e.g. png.

However, there are severe problems with sliced XPM images, at least on X.  

The clip mask for each slice is taken from top/leftmost part of the
image, rather than the actual slice of the image.  I have tried a
zillion things to setup the clip mask (and rewrite other parts of the
code) to make this work, but to no avail.

So I hereby ask for help from more skilled X people.  How do you setup
the clip mask of an image with an image mask so that XCopyArea will
use the corresponding part of the image mask when copying a slice from
the image ?

Here is some code to illustrate the bug:

(progn
  (setq im2 (find-image '((:type xpm :file "gnus.xpm"))))
  (insert "\n")
  (insert-image im2)
  (insert "\n")
  (insert-sliced-image im2 nil nil 5 4)
  (insert "\n"))


Does this code work on W32 and/or MAC ?

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

Re: Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

> Here is some code to illustrate the bug:
>
> (progn
>   (setq im2 (find-image '((:type xpm :file "gnus.xpm"))))
>   (insert "\n")
>   (insert-image im2)
>   (insert "\n")
>   (insert-sliced-image im2 nil nil 5 4)
>   (insert "\n"))
>
>
> Does this code work on W32 and/or MAC ?

It looks OK on W32.

Re: Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 03 Jun 2004 23:45:42 +0100, Jason Rumney <jasonr@gnu.org> said:

> storm@cua.dk (Kim F. Storm) writes:

>> Here is some code to illustrate the bug:
>> 
>> (progn
>> (setq im2 (find-image '((:type xpm :file "gnus.xpm"))))
>> (insert "\n")
>> (insert-image im2)
>> (insert "\n")
>> (insert-sliced-image im2 nil nil 5 4)
>> (insert "\n"))
>> 
>> 
>> Does this code work on W32 and/or MAC ?

> It looks OK on W32.

OK on MAC, too.

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

Re: Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[Kim F. Storm]

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

> >>>>> On Thu, 03 Jun 2004 23:45:42 +0100, Jason Rumney <jasonr@gnu.org> said:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> 
> >> Here is some code to illustrate the bug:
> >> 
> >> (progn
> >> (setq im2 (find-image '((:type xpm :file "gnus.xpm"))))
> >> (insert "\n")
> >> (insert-image im2)
> >> (insert "\n")
> >> (insert-sliced-image im2 nil nil 5 4)
> >> (insert "\n"))
> >> 
> >> 
> >> Does this code work on W32 and/or MAC ?
> 
> > It looks OK on W32.
> 
> OK on MAC, too.

Thank you both for testing.  So at least it is X specific.  X-perts? 

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

Re: Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[Jan D.]

> 
> Some time ago I installed changes to support image slices, and
> it works fine with e.g. png.
> 
> However, there are severe problems with sliced XPM images, at least on X.  
> 
> The clip mask for each slice is taken from top/leftmost part of the
> image, rather than the actual slice of the image.  I have tried a
> zillion things to setup the clip mask (and rewrite other parts of the
> code) to make this work, but to no avail.
> 
> So I hereby ask for help from more skilled X people.  How do you setup
> the clip mask of an image with an image mask so that XCopyArea will
> use the corresponding part of the image mask when copying a slice from
> the image ?
> 
> Here is some code to illustrate the bug:
> 
> (progn
>   (setq im2 (find-image '((:type xpm :file "gnus.xpm"))))
>   (insert "\n")
>   (insert-image im2)
>   (insert "\n")
>   (insert-sliced-image im2 nil nil 5 4)
>   (insert "\n"))

The thing to remember is that the clip_origin in the GC is relative to
the destination, never the source.  So in effect, a XCopyArea first
puts the mask on the destination at (clip_x, clip_y).  Then it copies the
bits from the source to the destination, where the mask is non-zero.

So if you want to use part of the mask that starts at mask coordinates
(x, y), you set (clip_x_origin, clip_y_origin) to (-x, -y) in the GC.
Not the most intuitive thing to do, but that's the way it is.

I've checked in the following patch, it makes the above test case work OK.
However, there seems to be more code that deals with slices, so there may be
other parts thats need this kind of modification also.

	Jan D.

Index: xterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.837
retrieving revision 1.838
diff -c -c -r1.837 -r1.838
*** xterm.c	16 Jun 2004 15:07:20 -0000	1.837
--- xterm.c	17 Jun 2004 19:35:00 -0000	1.838
***************
*** 2357,2364 ****
  	  XGCValues xgcv;
  
  	  xgcv.clip_mask = s->img->mask;
! 	  xgcv.clip_x_origin = x;
! 	  xgcv.clip_y_origin = y;
  	  xgcv.function = GXcopy;
  	  XChangeGC (s->display, s->gc, mask, &xgcv);
  
--- 2357,2364 ----
  	  XGCValues xgcv;
  
  	  xgcv.clip_mask = s->img->mask;
! 	  xgcv.clip_x_origin = x - s->slice.x;
! 	  xgcv.clip_y_origin = y - s->slice.y;
  	  xgcv.function = GXcopy;
  	  XChangeGC (s->display, s->gc, mask, &xgcv);

Re: Help fix this: Bug in sliced XPM images on X -- bad clip mask origin.

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> The thing to remember is that the clip_origin in the GC is relative to
> the destination, never the source.  So in effect, a XCopyArea first
> puts the mask on the destination at (clip_x, clip_y).  Then it copies the
> bits from the source to the destination, where the mask is non-zero.

Ah, that explains a few things :-)

> I've checked in the following patch, it makes the above test case work OK.

Thank you very much.

> However, there seems to be more code that deals with slices, so there may be
> other parts thats need this kind of modification also.

I haven't had problems with those parts, so I hope not :-)

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