Import of vwm3 changes from published source tgz

     Major changes from vwm2 include:

     - Introduction of integrated X client process and descendants
       monitoring in the form of per-window composited overlays.

       The rendering is done using the Composite, Damage, and Render
       extensions.  When the monitors are visible, vwm3 is a compositing
       manager.  When invisible, vwm3 continues to be an immediate-mode
       classic X11 minimalist window manager.

       Monitors are toggled via Mod1-;, Mod1-LeftArrow and Mod1-RightArrow
       may be used to decrease and increase the sampling frequency,
       respectively.  Mod1-' clears the monitored tasks history for the
       focused window when monitoring is visible.

       This feature depends on the CONFIG_CHECKPOINT_RESTORE kernel
       configuration option for the discovery of descendant processes.
       Without this kernel option enabled, you'll only get a single process
       monitored per window; the X client process as indicated by the
       _NET_WM_PID atom of the window.

       A library called libvmon has been introduced for the abstraction of
       lightweight system and process statistics sampling.

     Since vwm2 received backported features unrelated to monitoring or
     compositing while vwm3 was developed, there isn't really much
     difference between the two outside the monitoring context.

     This isn't to say there isn't much activity in the code, the addition
     of compositing and monitoring requires a substantial amount of code
     relative to the scale of vwm[12].

1 files changed, 95 insertions, 27 deletions

diff --git a/TODO b/TODO
index 3fd594d..350fe85 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,88 @@
+COMPOSITE (only relevant when monitoring overlays are enabled):
+- Sometimes popup dialogs seem to take more than one try to get displayed,
+  observed in GIMP during testing.  Right clicking in the image took two
+  tries.
+
+- There's often an extra row included after the process heirarchy in the
+  overlays.  This depends on wether the client process' monitor was installed
+  first by the automatic following of children in libvmon or the vwm explicit
+  process monitoring of _NET_WM_PID.  There's an extra row included depending
+  on how the race played out, and it's probably because count_rows() is
+  employed in xwin_monitor() to initialize xwin->heirarchy_end but it's not
+  making any effort to be proc->is_new aware or something.  Since an extra row
+  is relatively harmless I haven't bothered to fix it yet.
+
+- There are a number of optimization opportunities left on the table.
+  * The heirarchy (top) portion of the overlay text is redrawn on every
+    maintain_overlay(), even if it has no changes. (text only, not the graphs)
+    *** this has been changed to only happen if compositing is enabled.
+  * The shadow layer is inefficiently created with 4 renders through the text
+    as a stencil at 4 offsets to create a shadow on every compose_overlay()
+    call, even if the text is unchanged since the last compose.
+    - keep a cached version of the text shadow for reuse if the text is
+      unchanged. (depends not just on the heirarchy portion, _all_ the text
+      layer)
+    - find a better way to create the text shadow than 4x renders through the
+      stencil.
+    *** already improved with a shadow layer maintained as the text layer
+	changes.  When the heirarchy rendering becomes more change-aware, so
+        will the shadow updates.
+  * Snowflake maintenance is probably copying more area than it needs to when
+    shifting, it's not aware of snowflakes_cnt.
+  * Heirarchy rows are erased unnecessarily in maintain_overlays(), but this is
+    part of excessive heirarchy redraws.
+  * poll() timeout isn't calculated very well, extraneous wakeups and
+    gettimeofday() calls are being performed.
+    - This matters even when compositing is off, since we always maintain
+      monitoring, unless Hz is turned down to 0.
+  * Overlays are essentially triple buffered since they're composed into the
+    xwin->overlay.picture @ compose_overlay(), then paint_all() renders
+    xwin->overlay.picture into root_buffer after rendering xwin->picture into
+    the root_buffer in composing the screen contents, which then gets rendered
+    into root_picture where everything becomes visible.
+
+    It's possible to instead have compose_overlay render directly to
+    root_buffer after xwin->picture, but it makes things a bit more
+    complicated and will require some refactoring.
+
+    At least this overhead is only present when compositing is active.
+
+- Cleanups.  Much of the current compositing code is taken from a prototype
+  branch and merged with the latest vwm2 tree to create vwm3.  There are
+  numerous inconsistencies and just crufty things going on, but that will
+  improve with time.
+
+- libvmon could easily be monitoring other system things at little additional
+  cost:
+  * battery capacity/charging status/rate
+  * thermals
+  * cpu frequency
+  * diskstats
+  * network interface counters
+  * wireless interface signal strengths
+  it would be helpful to have another overlay visualizing these system-wide
+  things
+
+- There's a mildly annoying latency between switching Hz (Mod1-(Left|Right))
+  and its value changing visibly in the upper right corner of a window overlay.
+  This is mostly only noticable when switching to 1Hz.  The cause is that
+  status gets updated by the sampling callback, which is delayed by the
+  sampling interval.  When the interval is 1Hz, there's a ~1 second delay.
+
+  A refactoring should probably be done which allows maintain_overlays() to
+  have a redraw mode where no sampling has taken place and we want to simply
+  reproduce the last state, but we need to redraw everything in response to
+  things like Hz changing or a window reconfiguration.  (a similar latency is
+  observed when resizing a window, the overlay doesn't visibly adapt to the new
+  dimensions until the next sample is taken)
+
+  These are relatively minor issues, fixing them is a matter of polish IMO.
+
+- Streaming snowflakes to a png file when some kind of record button has been
+  pressed for the focused window would be interesting.  Not to produce an
+  animation of any sort, but more like a scrolled record.
+
+
 XINERAMA:  
 - XRandR events removing screens containing windows turns them into
   pseudo-phantom windows.  You can reclaim them by Mod1-Tabbing to them (which
@@ -162,13 +247,6 @@ BUGS:
 
   (this bug entry has become a feature monologue)
 
-- Virtual desktop window unmap/map sequences aren't Z-ordered, this causes some
-  visual artifacts when switching desktops depending on how things happen to
-  be ordered.  Fixing this requires maintaining a windows list in the same
-  stacking order as the X server, worth fixing, and will be needed anyways when
-  I integrate the composited window child monitoring code.  There are features
-  below which also would benefit from the ability to preserve window stacking.
-
 
 FEATURES:
 
@@ -186,7 +264,7 @@ FEATURES:
   --help invocation or two.
 
   For instance, these days I'm often getting on various wireless networks and I
-  invoke wpa supplicant directly using a locale-named configuration file as
+  invoke wpa_supplicant directly using a locale-named configuration file as
   root largely via an reverse history search of the locale's name.
 
   What I do today is I create an xterm for wpa_supplicant and shelve it, which
@@ -217,15 +295,6 @@ FEATURES:
 
   Unsure.
 
-- Multihead-awareness?  I don't really have a setup to mess with this on right
-  now, which also removes the pressure from me to actually make it
-  well-integrated.  However, I've used xrandr --same-as configurations for
-  watching movies on a projector, and provided I set the external display as
-  the "primary" (xrandr terminology) then things like allscreen use the
-  appropriate geometry for the external display.  Upon stopping the external
-  usage I need to disable the output or set the internal one as primary etc to
-  restore internal display correctness for geometry-dependent functionality.
-
 - Mod1+enter currently toggles between the currently user-specified (starts out
   at client-configured) dimensions, and full-screen.  I think it would be useful
   to support 3 states, the client's originally configured dimensions, the
@@ -234,6 +303,9 @@ FEATURES:
   be very intuitive to sometimes have 3 persisted window states vs. 2, depending
   on if the user has reconfigured the window dimensions, perhaps it should just
   always be 3 but sometimes 2 of them are identical.
+  *** this is slightly different now, but I still think it might be useful to
+  keep the original client-supplied configuration available, so a tristate may
+  be cool, keeping the bug entry for the time being.
 
 - Mod1+right click resizing should insert a short delay before actually applying
   motion events for resizing, this better facilitates the use case of
@@ -251,10 +323,6 @@ FEATURES:
   raised when they were visited but restored to their previous position in the stack
   at the subsequent tab press.
 
-- Window cycling should probably be reversible (shift+Mod1+Tab?)
-  *** strangely lacking this hasn't really annoyed me, MRU keeps things
-      mostly where you need them.
-
 - Window placement is static, at least cascade, preferably intelligent
   placement resorting to cascade when the desktop is filled.  I actually like how
   wmaker 'auto mode' tries to fill open spaces with window placement then falls
@@ -262,12 +330,7 @@ FEATURES:
   preferred size.
   *** funny how simply throwing all new windows in the corner is pretty damn
       acceptable, at least it's deterministic, moving it is easy enough.
-
-- An snap-to grid for window resize and movement may be useful, perhaps
-  activated by a modifier (shift?) pressed during the grab?  I'm not sure how I
-  feel about making windows snap to arbitrary alignments at neighboring window
-  borders vs. simply adhering to some fixed absolute grid totally ignorant of
-  other window boundaries.
+  *** still unsure on this, deterministic placement is pretty nice.
 
 - With the introduction of Mod1-[], Mod1-Shift-[] for halfscreens, and the
   repeaters for quarter windows, most appreciable XGA window layouts are
@@ -289,6 +352,11 @@ FEATURES:
   Or maybe it's simply good enough to restart from a toplevel half when you
   wish to effectively move up or laterally in the virtual quadtree.
 
+- Resistive edges would be handy, at least screen edges, but window edges can
+  be nice too.  It's not that much code to add it, and it makes things much
+  more usable for when the autoconfigured window options aren't fitting the
+  situation...
+
 - Virtual desktop genesis needs to query the user for the name, and create a
   full-screen xterm running screen -S $desktopname for the root (or something)
   (perhaps something like specifying special per-virtual-desktop classes to