Subject: CVS domivogt: * Increased menu item height by one pixel.

From: CVS <[email-masked]>
Date: Tue, 8 Jun 1999 17:48:50 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	99/06/08 17:48:50

Modified files:
	.              : ChangeLog 
	fvwm           : fvwm.c menus.c menus.h windowlist.c 
	libs           : Parse.c 

Log message:
* Increased menu item height by one pixel.
* More menu clean up (MakeMenu called only when necessary).

--
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: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 11:05:40 +0100

> * More menu clean up (MakeMenu called only when necessary).

If someone was going to change the way menu backgrounds were set, would
this be the place?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jun 1999 13:09:14 -0600

> If someone was going to change the way menu backgrounds were set, would

No. MakeMenu (now called make_menu) calculates the size of the menu and
manages the menu continuations. paint_menu() is the function that does
it.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Fri, 11 Jun 1999 13:24:28 -0600

> manages the menu continuations. paint_menu() is the function that does

BTW, Tim, how does your gradient code work now. Is the a single function
that creates a pixmap of a given size with a gradient in it? If yes,
could you modify the code so that creating the pixmap is in a different
function than the drawing itself? This way we could simply call the 
drawing functions, provide a drawable (i.e. a pixmap *or a window*)
and draw into it. This might come handy for the menu code when you
don't want to spend large amounts of memory on the pixmaps.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 13:04:00 +0100

Dominik Vogt wrote:
> that creates a pixmap of a given size with a gradient in it? 

Yes

> function than the drawing itself?

The drawing parts assume the drawble is of a certain size (dependent
upon the number of colors in the gradient and the gradient type). 
Making it draw in arbitrary sizes would mean factoring in the width and
height.  It wouldn't be too difficult as all the gradients are drawn in
loops like:

    case 'D':
      for (i = 0; i < width; i++) {
        for (j = 0; j < height; j++)
          XPutPixel(image, i, j, pixels[i + j]);
      }
      break;

You would just have to change this to

    case 'D':
      for (i = 0; i < width; i++) {
        x = i * (ncolors + 1) / 2 / width;
        for (j = 0; j < height; j++)
        y = j * (ncolors + 1 - ((ncolors - 1) / 2)) / height;
          XPutPixel(image, i, j, pixels[i + j]);
      }
      break;

> This way we could simply call the

My opinion on this is that if memory is tight don't use pixmaps at all
or just stick to HGradient/VGradient.  I think that simplifying the menu
code to always use a background pixmap would be better.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jun 1999 14:17:06 -0600

> upon the number of colors in the gradient and the gradient type). 

Duh, do you mean that I'll get a 1000x1000 pixmap when I use 1000 colours?

> code to always use a background pixmap would be better.

You underestimate the amout of memory these pixmaps use for menus. Since
you can't reuse the gradient pixmaps (thy all have different sizes) you'll
get one pixmap for each menu. If you have 50 menus (and some Linux distibs
make massive use of menus) this will use massive amounts of memory thus
rendering any gradients but v/h useless in many cases.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 14:37:07 +0100

> Duh, do you mean that I'll get a 1000x1000 pixmap when I use 1000 colours?

Duh, yes, you asked for 1000 colors, what's the point of returning a
10x10 pixmap with only 10% of the colors you asked for?  What you do
with this pixmap is CreateStrectchPixmap(window width, height) and use
the stretched (or shrunk pixmap) as the background of the window. The
end result is that the server has a pixmap the same size as the target
window.  If the size of the intermediate pixmap bothers you just use
fewer colors.

> rendering any gradients but v/h useless in many cases.

I guestimate that 50 menus ona 24 bit display will use 4 Mbytes 8-). The
size of the pixmap for each will be at most the size of the menu, much
less for V & H and zero for plain colors.  How much memory your menus
use will depend on the total area of the menus. If you're desparate we
could set the menus to have a CWBackingStore of NotUseful which might
save the same amount of memory for the server.

Cheers,
Tim.

---

From: Bob Woodside <[email-masked]>
Date: Fri, 11 Jun 1999 10:12:29 -0400

> rendering any gradients but v/h useless in many cases.

	Oh, *please* let's not render the diagonal gradients unusable. They're
the only kind I use in my menus.

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jun 1999 16:21:11 -0600

> the only kind I use in my menus.

No, I'm fighting hard to have them work no worse than at present :)
I have been experimenting with the gradients in the past few weeks.
V/H gradients are usable too if you use colours that are close to
each other. When I have completed my screen shots I can show you
what I mean.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jun 1999 19:37:01 +0200

> window.  If the size of the intermediate pixmap bothers you just use

But I don't know how big the menus will be when I write a config file.
With small menus, 50 colours will be enough, but if they fill half of
the screen I need 500 colours for a very smooth look. And is there
anti-aliasing code in the CreateStrectchPixmap() function? If not
a 20x20 pixmap (using 20 colours) stretched to 200x700 (a typical
menu) will more look like tetris that a B/D gradient. And I don't
dare to imagine a stretched yin-yang gradient :-)

... [ three minutes later ]

Ah, CreateStrectchPixmap() seems to tile the pixmap instead of strecting
it. That works only with V/H gradients.

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: Tim Phipps <[email-masked]>
Date: Fri, 18 Jun 1999 10:45:23 +0100

Dominik Vogt wrote:
> anti-aliasing code in the CreateStrectchPixmap() function?

No, I don't think allocating new colors would be a good idea in
StretchPixmap, it just stretches. If the result is too jaggy then the
original is too small. If the original is a gradient then the colors are
supposed to gradually change so the jaggies shouldn't be seen. You can't
expect gradients to look smooth on an 8 bit display.

> If not

If you go from black to white in 20 colors you will see steps in the
gradient no matter what method is used. If you go from #000077 to
#2222aa in 20 steps and you can see steps then your eyes are better than
mine (no cheating by using a 16 bit display, use a 24 bit one).

What I'm trying to say is that I understand gradients to be a gradual
change in colors and that this implies that stretching by large amounts
doesn't matter because you can't easily discern any one color from its
neighbours.

I had a quick play with using SetWindowBackground() in makemenu() so
that menus follow the DefaultBackground command.  V & H gradients and
TiledPixmap work fine but stretching to the full size of menus makes the
menus take too long to pop up the first time. I think the problem is
that makemenu() is called when the menu is about to be mapped.  This
could be fixed by calling makemenu() for all modified menus in the main
event loop just before the select call. I think this would mean that the
menus are ready to be mapped but they aren't rendered too often (i.e.
it's pointless to redraw the menus every time and AddToMenu is called)

Dominik, could you provide a code segment that runs through the list of
menus calling makemenu() if necessary? I'll try putting this in various
places to see if it speeds up response.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 13:54:09 -0600

On Fri, Jun 18, 1999 at 10:45:23AM +0100, Tim Phipps wrote:
> gradient no matter what method is used.

No, that's wrong. It depends on the contrast of the colours *and* the size
of the lines for each colour. You won't see steps with this gradient if
the drawing area is just 20 pixels wide. The bigger the window, the more
colours you need. But allocating colours takes up real execution time.
I tried it with 100 colours on my menus. It takes several seconds to
allocate them. So I want them only if I need them.

> If you go from #000077 to
> menus take too long to pop up the first time.

> I think the problem is
> menus are ready to be mapped but they aren't rendered too often

I spent quite some work to call make_menu only when it's really needed. The
problem is the MenuStyle. If that changes you'd have to update all menus in
a single sweep.

> (i.e. it's pointless to redraw the menus every time and AddToMenu is called)

??? Menus are never redrawn when mapped. make_menu is not called from
AddToMenu. That was the main goal of my work on make_menu.

> places to see if it speeds up response.

void update_all_menus(void)
{
  MenuRoot *mr

  for (mr = Menus.all; mr; mr = MR_NEXT_MENU(mr))
    update_menu(mr);
}

This is just a hack, it traverses the list much mor often than it is
necessacry, but if you don't use hundreds of menus you can get away
with it for now.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Tue, 22 Jun 1999 13:28:27 +0100

> allocate them. So I want them only if I need them.

I'm not sure what we're arguing about but the above applies to the
current method of doing gradient menus i.e. with a Vgradient you won't
know how many colors to allocate unless you know the height of your
tallest menu.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 17:55:38 +0200

> know how many colors to allocate unless you know the height of your

I can't remember most of the discussion either, but consider this:

  MenuStyle * MenuFace BGradient 20 colour1 colour2

Both colours are close together and I'm using a 16 bit display, making
it even worse. The tile is 20x20 pixels and the menu is 200x600 pixels.
With the current code I get a gradient consisting of 20 diagonal bars.
The gradient isn't very smooth, but it's acceptable if you don't expect
much. But if we would stretch by a factors of 10 and 30 you will not
get bars but ugly blocks. In the end I wouldn't use gradients on my 16
bit display any more (Or I would have to use much more colours that
would get th same pixel values, just to get the diagonal bars right).

Bye

Dominik ^_^