Subject: Opinions on new frame layout code?

From: Dominik Vogt <[email-masked]>
Date: Sun, 17 Mar 2002 22:49:01 +0100

Apart from the apparent bugs (windowshade doesn't do anything,
the border layout of small windows is screwed, window corners
sometimes flash above the parent during opaque resizing), what do
you think about the now code (mostly in terms of speed, but feel
free to comment on other aspects too)?

I'm not sure because my machine is so fast, but I think opaque
moving and resizing is already a lot faster.  When the bugs in the
border layout are fixed, I'll switch to using background pixmaps
in the title bar too and then take a look at window shading.

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: Mikhael Goikhman <[email-masked]>
Date: Mon, 18 Mar 2002 20:13:30 +0000

> in the title bar too and then take a look at window shading.

I am not sure what to say. Do you mean it is finished? :)

Maximize does not place right-aligned window buttons (I guess they are
covered by a title).

Resize (if done sharply) screws right-aligned window buttons, there is a
small positive or negative X offset depending on sharpness.

Style xv HandleWidth 10  # or any other number
does not update border geometries (looks terribly).
But at least Recapture/RecaptureWindow seem to work now.

WindowShade is disabled.

NoHandle does not work.

Try to resize the maximized window then cancel resizing, the window is
not maximized now as it was.

A good note:

On Resize borders (not title and buttons) do not flicker.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 18 Mar 2002 20:35:12 +0000

> WindowShade is disabled.

It is not really disabled, after it (when window IS_SHADED) Maximize and
RecaptureWindow do weird things. It would be better if it was disabled.

I only talk about usability. The current code is very unusable, but it
surely much more structured.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 18 Mar 2002 21:30:42 +0100

> free to comment on other aspects too)?

The big difference for me with the now code is that the borders
do not filcker at all during an opaque resize. This is really
a big progress IMHO. If a similar progress arise with the title
I think that fvwm will has a perfect resize operation.
About speed I can not say a lot as I never see speed problems
with the old code.

I see the following bugs:
- If I resize a window for a bigger width the left buttons positions
are wrong.
- After a Title{AtTop,Right,Left,AtBottom} style change the decoration
is totally screwed. A recapture is needed to get the good deco.

Olivier

---

From: Tim Phipps <[email-masked]>
Date: Tue, 19 Mar 2002 09:47:56 +0000

> free to comment on other aspects too)?

I didn't think it was worth the hassle of a rewrite to get opaque 
resizing to look nice but now I've seen it I'm convinced it was. Nice one.

The -visual option for fvwm2 now doesn't work, well it works but the 
borders, buttons and titles are left empty. Are you going to remove the 
option?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 11:50:11 +0100

> I am not sure what to say. Do you mean it is finished? :)

Of course.  I have lost interest in fvwm and am going to be a zsh
hacker now ;-)

> But at least Recapture/RecaptureWindow seem to work now.

This is all caused by the fact that a frame 'setup' operation can
not really be forced at the moment.  THat is one of the next
things to do.
 
> NoHandle does not work.

That's already fixed in CVS.

> not maximized now as it was.

The doesn't seem to be related with the frame rewrite - and I
don't see this here anyway.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Tue, 19 Mar 2002 11:51:01 +0100

> RecaptureWindow do weird things. It would be better if it was disabled.

Forget WindowShade for now.  It's a pile of garbage right now.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 11:53:13 +0100

> I think that fvwm will has a perfect resize operation.

I hope I'll get it done this weekend.

> About speed I can not say a lot as I never see speed problems

In the mean time I tested it myself at work where I have a much
slower machine with  a lousy video driver.  There is a *big*
difference between 2.4.x and current CVS in terms of speed.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 12:08:51 +0100

> resizing to look nice but now I've seen it I'm convinced it was. Nice one.

To be honest, I didn't start this all because of flicker free
animations and such but because I wanted to have window shading in
every direction.  But then, one thing led to the other and I did
not even start rewriting window shading yet :-)

> borders, buttons and titles are left empty.

I have no way to test this.  My display supports only TrueColor
and DirectColor, and both work fine.  Anyway, I forgot to change
the depth and visual attributes when I removed the decor_w.  That
is probably the cause.  Does it work with current CVS?

> Are you going to remove the option?

No.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 15:50:06 +0100

> But at least Recapture/RecaptureWindow seem to work now.

All fixed.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 19 Mar 2002 15:03:42 +0000

> > But at least Recapture/RecaptureWindow seem to work now.

Fine, but now right button numbers are reversed, i.e.
  24680
instead:
  08642

You say that you can't reproduce this? Resize maximized window and
cancel resizing, the window is marked maximized (toggled), but can't be
unmaximized anymore (the original geometry is lost).

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 19 Mar 2002 15:26:24 +0000

> is probably the cause.  Does it work with current CVS?

Nearly, you have to specify a colormap and a border pixel when creating 
non-root visual windows, and the gcs used to fill the borders have to be 
created from an fvwm visual window. I've attached a patch from todays 
snapshot but it may be out of date already.

Cheers,
Tim.

Index: fvwm/add_window.c
===================================================================
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/add_window.c,v
retrieving revision 1.34
diff -u -r1.34 add_window.c
--- fvwm/add_window.c	2002/03/19 12:48:34	1.34
+++ fvwm/add_window.c	2002/03/19 13:44:31
@@ -1173,10 +1173,13 @@
 		pattributes->background_pixmap = None;
 	}
 
-	*pvaluemask |= CWBackingStore | CWCursor | CWSaveUnder;
+	*pvaluemask |= CWBackingStore | CWCursor | CWSaveUnder
+		| CWBorderPixel | CWColormap;
 	pattributes->backing_store = NotUseful;
 	pattributes->cursor = Scr.FvwmCursors[CRS_DEFAULT];
 	pattributes->save_under = False;
+	pattributes->border_pixel = 0;
+	pattributes->colormap = Pcmap;
 
 	return;
 }
@@ -1407,10 +1410,13 @@
 	{
 		return;
 	}
-	valuemask = CWEventMask | CWBackingStore | CWSaveUnder | CWWinGravity;
+	valuemask = CWEventMask | CWBackingStore | CWSaveUnder | CWWinGravity
+		| CWBorderPixel | CWColormap;
 	attributes.event_mask = XEVMASK_BORDERW;
 	attributes.backing_store = NotUseful;
 	attributes.save_under = False;
+	attributes.border_pixel = 0;
+	attributes.colormap = Pcmap;
 	/* Just dump the windows any old place and let frame_setup_window take
 	 * care of the mess */
 	for (i = 0; i < 4; i++)
Index: fvwm/borders.c
===================================================================
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/borders.c,v
retrieving revision 1.22
diff -u -r1.22 borders.c
--- fvwm/borders.c	2002/03/18 12:47:10	1.22
+++ fvwm/borders.c	2002/03/19 14:29:23
@@ -1426,7 +1426,7 @@
 	{
 		XGCValues xgcv;
 
-		tile_gc = fvwmlib_XCreateGC(dpy, FW_W_FRAME(fw), 0, &xgcv);
+		tile_gc = fvwmlib_XCreateGC(dpy, Scr.SizeWindow, 0, &xgcv);
 	}
 	ret_gcs->tile = tile_gc;
 	/* setup the tile gc*/

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 16:31:04 +0100

> Fine, but now right button numbers are reversed, i.e.

Oops.

> unmaximized anymore (the original geometry is lost).

No.  That work fine for me.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 15:51:12 +0100

> is totally screwed. A recapture is needed to get the good deco.

Should work now.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 16:45:51 +0100

> snapshot but it may be out of date already.

Hm, I'm not sure I understand this well enough.  Can you remake
the patch with the next snapshot please?

Bye

Dominik ^_^  ^_^

---

From: tim phipps <[email-masked]>
Date: Wed, 20 Mar 2002 15:21:53 +0000

> the patch with the next snapshot please?

Yur tiz

Index: fvwm/add_window.c
===================================================================
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/add_window.c,v
retrieving revision 1.35
diff -u -r1.35 add_window.c
--- fvwm/add_window.c	2002/03/20 14:07:02	1.35
+++ fvwm/add_window.c	2002/03/20 14:07:33
@@ -1173,10 +1173,13 @@
 		pattributes->background_pixmap = None;
 	}

 	return;
 }
@@ -1407,10 +1410,13 @@
 	{
 		return;
 	}
retrieving revision 1.23
diff -u -r1.23 borders.c
--- fvwm/borders.c	2002/03/20 14:07:02	1.23
+++ fvwm/borders.c	2002/03/20 14:07:33
@@ -1426,7 +1426,7 @@
 	{
 		XGCValues xgcv;

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 22:13:58 +0100

> snapshot but it may be out of date already.

Ah yes, understood.  The fix will be in my next commit.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 20 Mar 2002 23:04:02 +0100

> in the title bar too and then take a look at window shading.

So, with my last commit, title buttons are drawn as smoothly as the
borders.  That part of the code isn't finished yet.  Some features
of the ButtonStyle are unavailable and the title window is blank,
but it gives a good impression of the speed and smoothness with
opaque resizing.

Bye

Dominik ^_^  ^_^

---

From: Dave Trollope <[email-masked]>
Date: Thu, 21 Mar 2002 23:31:46 -0600

Hi,

I recently downloaded and compiled fvwm2 for cygwin (having been using
it on solaris for years) and was pleased to have it compile and run
first time.

However, cygwin is a little slow and I was curious about the fvwm2
source, so I downloaded it and decided to see if there was anything
(even in the smallest way) to improve performance.

I think I found something that could improve general performance which I
describe below, and would welcome feedback on whether to implement this.

1) I came across libs/safemalloc.c.

I was surprised that malloc was wrapped in a function like this since
this is called whenever something is put on the (I think) event queue.
Everytime I move the pointer from one window to another, launch tools
etc, safemalloc is called. Wrapping malloc in a function is an overhead
that will cause branches from the CPU cache probably when only one is
necessary (the actual call to malloc itself).

So #if 0'd out the safemalloc, safecalloc, saferealloc functions and
recoded them as macros. E.G.

#define safemalloc(length) \
   (malloc((length) <= 0 ? 1 : (length)) ? : (char
*)alloc_failed("malloc",(length)))

The main advantage of this is that only one function call for each
malloc is required (malloc itself) instead of two (safemalloc+malloc).
?: is supposed to be more efficient than if () but I'm not sure thats
really true. If I could only disassemble the code.... Suggestions? One
function call should reduce the number of branches (and therefore cache
usage is improved).

The biggest disadvantage of this however is that the binary size
increases because these decisions (length <= 0) are duplicated
everywhere. Somewhat prone to casting issues of length.

2) The other related issue I found was that in some cases, dynamic
memory is used for simple temporary use. Local stack arrays are much
more efficient for this, however you don't want to restrict the size of
the data being processed. I suggest that the majority of users will have
little data and most optimisation can come from putting those into a
local array, and only calling on safemalloc when handling larger data
quantities.

libs/Graphics.c - do_relieve_rectangle

  XSegment* seg,segarr[5];

..

  if(line_width > 5)

    seg = (XSegment*)safemalloc(sizeof(XSegment) * line_width);

  else

    seg = &segarr[0];

...

  if(line_width > 5)

     free(seg)

This would completely remove the malloc for 90% of users.

I have half a dozen of these kind of things and a place or two where
memset is called prior to a memcpy that overwrites the same block memset
cleared.

What do you think? While these are trivial changes, for a function that
is called hundreds of times, even a small gain adds up. Shall I go ahead
and make these changes? Perhaps as I grow more experienced with the
fvwm2 source I can find some bigger issues.

Cheers
Dave

---

From: Dan Espen <[email-masked]>
Date: Fri, 22 Mar 2002 10:57:07 -0500

Dave Trollope <[email-masked]> writes:
> really true. If I could only disassemble the code.... Suggestions?

This is for gcc, every compiler I've seen has similar options:

     -S    Stop after the stage of compilation proper; do not as-
          semble.   The output is an assembler code file for each
          non-assembler input file specified.

          By default, GCC makes the assembler  file  name  for  a
          source  file  by replacing the suffix `.c', `.i', etc.,
          with `.s'.  Use -o to select another name.

Be sure to compile optimized, I don't think ?: would have any
advantage over if in properly optimized code.

Maybe you want to quantify some of the memory impacts.

Please, don't send us HTML.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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: Dave Trollope <[email-masked]>
Date: Fri, 22 Mar 2002 19:26:36 -0600

Hi Dan,

>           with `.s'.  Use -o to select another name.

I wondered about creating the assembler file that way. I wasn't sure if
there was a tool that provided a better output. My past experience showed
compiler generated assembler was less easy to read than that of dedicated
disassemblers but I will gibe it a go and take a peek.

> Maybe you want to quantify some of the memory impacts.

I specifically didn't try to get too detailed on this because everyones
configuration is different, with different modules loaded, configured etc,
so I decided to see if there was any value pursuing this before I spent too
much time doing it! There certainly seems to be some things that I can look
at.

> Please, don't send us HTML.

Oops - sorry. I realised I'd goofed just after it went. I won't do it again!

Dave