Re: visible window rectangle in pixmap redirection

["varun shrivastava" <iluvubuntu gmail com>]

hi
   the patches provided in the bugzilla  are causing trouble while patching 
After patchingg all individual patches  and last patch by Tim, i found this

gdkevent.c 
    656       case GDK_PROXIMITY_OUT:
    657       case GDK_DAMAGE:               <<<<<<<<<<<<<<<<<<<
    658       case GDK_DRAG_ENTER:
    659       case GDK_DRAG_LEAVE:
    660       case GDK_DRAG_MOTION:
    661       case GDK_DRAG_STATUS:
    662       case GDK_DROP_START:
    663       case GDK_DROP_FINISHED:
    664       case GDK_NOTHING:
    665       case GDK_DELETE:
    666       case GDK_DESTROY:
    667       case GDK_EXPOSE:
    668       case GDK_MAP:
    669       case GDK_UNMAP:
    670       case GDK_WINDOW_STATE:
    671       case GDK_SETTING:
    672       case GDK_OWNER_CHANGE:
    673       case GDK_GRAB_BROKEN:
    674       case GDK_DAMAGE:                 <<<<<<<<<<<<<<<<<<<
    675         /* no state field */

 
gdkevents.h  ::  GDK_DAMAGE = 36  some how goes missing, its there in patch but after applying all the patches its not there

two declaration for GdkWindowClipData

and multiple definitions of some functions in gdkwindow.c and gtkwindow.c

i think the individual patches are from git and last patch by Tim is from some other repos. which is causing trouble patching the source

can a fresh single patch for all of them can be posted , i would be thankful to you.

i patched the patches serially , as they are on bugzilla, if there is some other order in which the patches needs to be applied 
kindly tell me.

thanks 
varun

On Wed, Feb 13, 2008 at 3:17 PM, Alexander Larsson <alexl redhat com> wrote:

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.

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list