[gtk+] Remove old comment about guffaw scrolling

[Alexander Larsson <alexl src gnome org>]

commit 0fc8c475a840527ec9a4bb030939f7c7e0dc0bde
Author: Alexander Larsson <alexl redhat com>
Date:   Mon Aug 10 14:27:53 2009 +0200

    Remove old comment about guffaw scrolling
    
    We no longer use guffaw scrolling since the client side windows
    branch was merged.

 gdk/x11/gdkgeometry-x11.c |  112 ---------------------------------------------
 1 files changed, 0 insertions(+), 112 deletions(-)
---
diff --git a/gdk/x11/gdkgeometry-x11.c b/gdk/x11/gdkgeometry-x11.c
index 6bd71c3..50d7548 100644
--- a/gdk/x11/gdkgeometry-x11.c
+++ b/gdk/x11/gdkgeometry-x11.c
@@ -17,118 +17,6 @@
  * Boston, MA 02111-1307, USA.
  */
 
-/* gdkgeometry-x11.c: emulation of 32 bit coordinates within the
- * limits of X. 
- *
- * By Owen Taylor <otaylor redhat com>
- * Copyright Red Hat, Inc. 2000
- *
- * The algorithms implemented in this file are an extension of the
- * idea of guffaw scrolling, a technique (and name) taken from the classic
- * Netscape source code. The basic idea of guffaw scrolling is a trick
- * to get around a limitation of X: there is no way of scrolling the
- * contents of a window. Guffaw scrolling exploits the X concepts of
- * window gravity and bit gravity:
- *
- *  window gravity: the window gravity of a window affects what happens
- *   to a windows position when _its parent_ is resized, or
- *   moved and resized simultaneously.
- *
- *  bit gravity: the bit gravity of a window affects what happens to
- *  the pixels of a window when _it_ is is resized, or moved and
- *  resized simultaneously.
- *
- * These were basically intended to do things like have right
- * justified widgets in a window automatically stay right justified
- * when the window was resized, but there is also the special
- * "StaticGravity" which means "do nothing." We can exploit
- * StaticGravity to scroll a window:
- *
- *     |  VISIBLE  |
- * 
- *     |abcdefghijk|
- *     |abcdefghijk    |   (1) Resize bigger
- * |    efghijk    |       (2) Move  
- *     |efghijk    |       (3) Move-resize back to the original size
- *
- * Or, going the other way:
-
- *     |abcdefghijk|
- * |    abcdefghijk|       (1) Move-resize bigger
- *     |    abcdefghijk|   (2) Move  
- *     |    abcdefg|       (4) Resize back to the original size
- *
- * By using this technique, we can simulate scrolling around in a
- * large virtual space without having to actually have windows that
- * big; for the pixels of the window, this is all we have to do.  For
- * subwindows, we have to take care of one other detail - since
- * coordinates in X are limited to 16 bits, subwindows scrolled off
- * will wrap around and come back eventually. So, we have to take care
- * to unmap windows that go outside the 16-bit range and remap them as
- * they come back in.
- *
- * Since we are temporarily making the window bigger, this only looks
- * good if the edges of the window are obscured. Typically, we do
- * this by making the window we are scrolling the immediate child
- * of a "clip window".
- *
- * But, this isn't a perfect API for applications for several reasons:
- *
- *  - We have to use this inefficient technique even for small windows
- *    if the window _could_ be big.
- *  - Applications have to use a special scrolling API.
- *
- * What we'd like is to simply have windows with 32 bit coordinates
- * so applications could scroll in the classic way - just move a big
- * window around.
- *
- * It turns out that StaticGravity can also be used to achieve emulation
- * of 32 bit coordinates with only 16 bit coordinates if we expand
- * our horizons just a bit; what guffaw scrolling really is is a way
- * to move the contents of a window a different amount than we move
- * the borders of of the window. In the above example pictures we
- * ended up with the borders of the window not moving at all, but
- * that isn't necessary.
- *
- * So, what we do is set up a mapping from virtual 32 bit window position/size
- * to:
- *
- *  - Real window position/size
- *  - Offset between virtual coordinates and real coordinates for the window
- *  - Map state (mapped or unmapped)
- *
- * By the following rules:
- *
- *  - If the window is less than 32767 pixels in width (resp. height), we use it's
- *    virtual width and position.
- *  - Otherwise, we use a width of 32767 and determine the position of the window
- *    so that the portion of the real window [16384, 16383] in _toplevel window
- *    coordinates_ is the same as the portion of the real window 
- *
- * This is implemented in gdk_window_compute_position(). Then the algorithm
- * for a moving a window (_window_move_resize_child ()) is:
- * 
- *  - Compute the new window mappings for the window and all subwindows
- *  - Expand out the boundary of the window and all subwindows by the amount
- *    that the real/virtual offset changes for each window. 
- *    (compute_intermediate_position() computes expanded boundary)
- *  - Move the toplevel by the amount that it's contents need to translate.
- *  - Move/resize the window and all subwindows to the newly computed
- *    positions.
- *
- * If we just are scrolling (gdk_window_guffaw_scroll()), then things
- * are similar, except that the final mappings for the toplevel are
- * the same as the initial mappings, but we act as if it moved by the
- * amount we are scrolling by.
- *
- * Note that we don't have to worry about a clip window in
- * _gdk_window_move_resize() since we have set up our translation so
- * that things in the range [16384,16383] in toplevel window
- * coordinates look exactly as they would if we were simply moving the
- * windows, and nothing outside this range is going to be visible
- * unless the user has a _really_ huge screen.
- */
-
 #include "config.h"
 #include "gdk.h"		/* For gdk_rectangle_intersect */
 #include "gdkprivate-x11.h"