Subject: Drawing Menu Items

From: Remko Troncon <[email-masked]>
Date: Wed, 10 Jul 2002 22:12:18 +0200

Hi,

There seems to be a problem in the drawing of menus. The problem is as follows:
I have a grey/white DGradient as a background of my menus. When i use FreeType
fonts as my menu font, the gradient doesnt show at all, i only get a
plain grey background.
I tried to trace the problem, and stumbled upon some code in menuitem.c. 
In menuitem_paint(), there is a piece of code
     ...
     else if ( xft_redraw || ... ) {
         ...
         XClearArea(...)
     }
When i comment the XClearArea (or the xft_redraw condition), the
gradient does show. I've never programmed with Xlibs before, so i don't
really know how the XClearArea works, so maybe someone can help me find
out what could be going wrong ?

thanks,
Remko
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 22:45:02 +0200

> out what could be going wrong ?

The XClearArea() call erases the foreground of the window so that
the window backgorund shines through.  The reason why this doesn't
work with b and d gradients is that they are drawn on the window
*foreground* (unlike all other types of gradients).  That happens
only with the

  MenuFace B/DGradient ...

options.  If you instead define a colorset with the gradient and
then set

  MenuFace Colorset ...

it works as expected.

Olivier:  I guess you added that XClearArea() call.  Do you know
of any other places in the menu code where you added similar
calls?  We should continue to support direct gradient drawing
since they look a lot better this way (less blocky).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 23:03:42 +0200

> since they look a lot better this way (less blocky).

Or maybe we should not?  All the Xft, tinting and alpha rendering
stuff is going to become very complex, just because of these two
gradient types.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 10 Jul 2002 22:02:19 +0000

On 10 Jul 2002 22:45:02 +0200, Dominik Vogt wrote:
> 
> That happens only with the
> 
>   MenuFace B/DGradient ...
> 

Dominik wanted to say here:

  MenuStyle * MenuColorset 5, ActiveColorset 6

> We should continue to support direct gradient drawing

Hmm, I didn't know they use 2 different methods.

Maybe solid color blocks in colorset gradients should be placed depending
on the gradient type? Placing them in a rectangular grid is only good for
{H,V,S}Gradient.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 11 Jul 2002 08:18:18 +0200

On Wed, Jul 10, 2002 at 10:45:02PM +0200, Dominik Vogt wrote:
> > gradient does show. 

But the text may become ugly. With xft we cannot draw text onto a given
text as the drawing procedure take in account what is under the text
which is drawn.

> > I've never programmed with Xlibs before, so i don't

I do not think that there is an other place in the menu code
where I added such clearing. I was not award that B/DGradient
is drawn on the foreground. 

But what about redrawing the relevant part of the gradient
in this case: in the place of the XClearArea put (around
line 404 of menuitems.c (+ do paint_menu_gradient_background
global (menus.c + menus.h) and pass mr in some way to
menuitem_paint).

		if (xft_redraw && !ST_HAS_MENU_CSET(ms) && 
		    ST_FACE(ms).type == GradientMenu &&
		    (ST_FACE(ms).gradient_type == D_GRADIENT ||
		     ST_FACE(ms).gradient_type == B_GRADIENT))
		{
			XEvent e;

			e.xexpose.x = MDIM_ITEM_X_OFFSET(*dim);
			e.xexpose.y = y_offset + d;
			e.xexpose.width = MDIM_ITEM_WIDTH(*dim);
			e.xexpose.height = y_height + relief_thickness - d;
			paint_menu_gradient_background(mr, &e);
                                                       ^^pbs
		}
		else
		{
			XClearArea(
				dpy, mpip->w, MDIM_ITEM_X_OFFSET(*dim),
				y_offset + d, MDIM_ITEM_WIDTH(*dim),
				y_height + relief_thickness - d,
				0);
		}

Anyway, maybe the good solution is to paint the _all_ menu into
the background (with the selected item drawn on an additional
window). This will supress all flickering which come from
xft redrawing ...

Olivier

PS: I'am not at home for a few weeks and I've at present time some
pbs with my internet connection.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Jul 2002 11:24:35 +0200

> Hmm, I didn't know they use 2 different methods.

I couldn't remember either until I debugged the problem Remko
reported yesterday.

> Maybe solid color blocks in colorset gradients should be placed
> depending on the gradient type?

They are not really placed

> Placing them in a rectangular grid is only good for {H,V,S}Gradient.

Not always.  In a window title, B and D gradients would look
almost exactly like HGradient if the lines were always drawn at
45 degrees.  In rectangles with a more even aspect ratio (menus
for example), the old way looks a bit better.

> global (menus.c + menus.h) and pass mr in some way to

[snip]

I now remember why we are drawing in the foreground.  It's not
because of the looks but because a potentially huge pixmap has to
be kept in XServer memory.  I'm unwilling to add a lot of
additional code just for the benefit of the old B/DGradient
implementation.  Should we just document that a few features do
not work with the old gradient code?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Jul 2002 11:30:23 +0200

> They are not really placed

... but stretched to their final size.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 11 Jul 2002 12:19:00 +0000

> ... but stretched to their final size.

Yes, but maybe the algorithm of enlarging a gradient rectangle should be
different than just granulation.

> > for example), the old way looks a bit better.

Well, TitleStyle does this itself without colorsets, so it is impossible
currently to compare these 2 methods in titles.

Of course keeping only 45 degrees like in non-colorset gradients is bad.
Here is another formula for stretching DGradient that I had in mind
when wrote the original message, it is none of the existing two:

	get_color_index(x, y, size_x, size_y, colors_num)
	{
		(x / size_x + y / size_y) * colors_num / 2
	}

This should produce something like:

  11111....333
  111....3333:
  1....3333:::
  ...3333::::5
  .3333::::555
  333::::55555

Compare with the existing ones:

  1111....3333
  1111....3333
  ....3333::::
  ....3333::::
  3333::::5555
  3333::::5555

and:

  111....3333:
  11....3333::
  1....3333:::
  ....3333::::
  ...3333::::5
  ..3333::::55 

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Jul 2002 14:38:59 +0200

> This should produce something like:

That's what the menu code is doing.

> Compare with the existing ones:

That's what the Colorset code does.

This is what the title drawing code does.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 11 Jul 2002 13:07:50 +0000

> That's what the menu code is doing.

I don't see that this is used anywhere although this is the most logical.

> This is what the title drawing code does.

This is what menu gradients do as well.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Jul 2002 15:19:48 +0200

> I don't see that this is used anywhere although this is the most logical.

Try

  MenuStyle * MenuFace BGradient 3 red green

and you'll see it clear as day.

> This is what menu gradients do as well.

Only when using colour sets, not with the native menu code.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 11 Jul 2002 13:25:06 +0000

> and you'll see it clear as day.

Yes, I see it clear as day that 45 degrees used, not 30 as in my formula.

> Only when using colour sets, not with the native menu code.

No, this is what native menu DGradient does, not colorsets.
Unless we use different fvwm-s of course. :)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Jul 2002 15:27:44 +0200

> Unless we use different fvwm-s of course. :)

No, I think we use different fonts in mutt.  The first one exactly
looks like 45 degrees and the last one like 60 degrees. :-)

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Thu, 11 Jul 2002 15:48:45 +0100

>This should produce something like:
This is nice. I think the way colorsets are stretched at the moment is a 
result of trying too hard to keep the code small. The existing code 
stretches the gradient horizontally to the window width
and then stretches the resulting intermediate pixmap vertically to fit 
the window height. This reuses the horizontal and vertical streching 
code used for HGradients and VGradients. There's no reason not to add 
your algorithm in for colorsets that need to be streched both ways. It 
would help all the gradients (apart from V & H) become less blocky.

The code to change is in CreateStretchPixmap() in libs/Graphics.c. It 
currently does a CreateStretchXPixmap() followed by a 
CreateStretchYPixmap().

The downside is performance for large areas and I'm not sure if it would 
be an improvement for colorsets that use a small pixmap file as a 
non-tiled background (but they look bad anyway)

>Compare with the existing ones:
Hmm, Tetris! Maybe we could create a game in Fvwm using FvwmForm/Script 
to capture keystrokes and fire off Colorset definitions 8-).

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 12 Jul 2002 07:56:37 +0200

> not work with the old gradient code?

As the fix is simple and does not change a lot of code, I've
fixed old D/BGradient with xft fonts.

Olivier