Re: visible window rectangle in pixmap redirection

[Alexander Larsson <alexl redhat com>]

On Tue, 2008-02-12 at 17:44 +0100, Tim Janik wrote:
> hi Alex.
> 
> it'd be great if you could take a look at my latest comment on the
> offscreen windows bug report, i.e.:
>    http://bugzilla.gnome.org/show_bug.cgi?id=318807#c48
> 
> it adresses just the pixmap redirection portions that you split off
> some while ago and lists remaining issues that need solving before
> inclusion.
> in particular, i'd like to know:

Lets start with this one:

> - why is _gdk_windowing_window_get_visible_rect() a backend specific
>    function? couldn't we get the visible rectangle of a window from
>    window->parent->width/height and window->x/y?

That is not the whole truth, what if the parent window is the same
size as the window, but the grandparent is much smaller.
You really need to look at all parents up to the toplevel to see what
parts are visible on the toplevel (and in X terms, up to the root window
to see what is visible on the screen, but X does the last part for us).

> - gtk_widget_get_snapshot() is supposed to snapshot whole widgets
>    (i.e. all of widget->allocation.width/height).
>    so why is gdk_window_end_paint() calling
>    _gdk_window_calculate_full_clip_region() (indirectly via
>    setup_redirect_clip()) to constrain the redirected area
>    to the visible widget area?

Yes, this seems obviously wrong for the case of get_snapshot(). But I
can see where its coming from, and its related to the previous
question. Consider the case where we're redirecting a whole toplevel
window, and we're repainting a widget that is inside a scrolled
window, thus being partially clipped by its parents. If we didn't take
that into account in end_paint() when drawing that widget we'd draw on
the redirected pixmap outside of the area where the window should be
visible.

I.E, things look like this:

+------------------------+
|    redirected          |
|    toplevel            |
| +-----------+          |
| | scrollled |          |
| | window    |          |
| |       +---|- - - - + |
| |       |   |button  : |
| +----------+         : |
|         :            : |
|         +- - - - - - + |
|                        |
+------------------------+

In this case, with the full toplevel redirected, when exposing the
button we clearly have to clip the drawing into the limits of the
scrolled window.

The same is true when exposing the button if you call
gtk_widget_get_snapshot() on the scrolled window, you don't want to
affect the target pixmap outside the size of the scrolled window.
However, if you're calling gtk_widget_get_snapshot() on the button
itself you really want to see all of it.

So, the issue is not that gdk_window_calculate_full_clip_region()
clips to parents, the issue is that it always clips to all parents. I
think the right solution is to only clip up to the parent that has the
redirection set.
   
> - i'm wondering if there is a use case at all for snapshooting *only*
>    the visible area of a widget. i think the semantics of
>    gtk_widget_get_snapshot() are fine if it snapshoots all of a
> widgets
>    allocation, and i'd like to get rid of all the clip-to-visible-rect
>    logic. if there is indeed a use case for snapshoting only the
>    visible portion of a widget (afaics relevant in scrolled window
>    contexts only), we should be able to simply provide:
>      void gtk_widget_get_visible_rect (Widget*, Rect*);
>    that provides coordinates for use with gtk_widget_get_snapshot().

I don't think that is really required.