Subject: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no

From: YAMAMOTO Mitsuharu <[email-masked]>
Date: Wed, 07 Apr 2010 18:48:22 +0900

>>>>> On Wed, 07 Apr 2010 11:18:25 +0200, Jan Djärv <[email-masked]> said:

>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
>> top side internal border width, respectively.  So, the internal border
>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.

> Upon further investigation, this is true for cols, but not always for lines.
> We have

> #define FRAME_LINE_TO_PIXEL_Y(f, row) \
>    ((row < FRAME_TOP_MARGIN (f) ? 0 : FRAME_INTERNAL_BORDER_WIDTH (f))	\
>     + (row) * FRAME_LINE_HEIGHT (f))

> So if row is less than FRAME_TOP_MARGIN (which is menu bar lines + tool bar 
> lines), internal border width is not added.  That makes sense for 
> FRAME_LINE_TO_PIXEL_Y as the internal border is below the tool bar.  But it is 
> not correct for
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT, which is supposed to return the total frame 
> size.  When setting wm size hints, this call

>      base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);

> will return just one internal border.  Thus, a pixel is missing.
> Thanks for pointing me in the right direction.

FRAME_LINE_TO_PIXEL_Y used to be 

#define FRAME_LINE_TO_PIXEL_Y(f, row) \
  (FRAME_INTERNAL_BORDER_WIDTH (f)  \
   + (row) * FRAME_LINE_HEIGHT (f))

and I changed the definition as you quoted so it takes account of the
`row < FRAME_TOP_MARGIN (f)' case in order to draw and handle events
for non-toolkit menu/tool bars correctly.  Actually I seem to have
overlooked the `base_height' calculation by specifying 0 as the number
of lines.  (Also, `row' should have been parenthesized.)

				     YAMAMOTO Mitsuharu
				[email-masked]