Fwd: visible window rectangle in pixmap redirection
hi how to get popup menus created with gtk_popup_new() with 2nd and 3rd arguments as NULL, to offscreen window as they are GDK_WINDOW_TEMP not GDK_WINDOW_CHILD if i am not correct please let me know thanks -- Forwarded message -- From: Tim Janik <[EMAIL PROTECTED]> Date: Fri, Feb 22, 2008 at 6:38 PM Subject: Re: visible window rectangle in pixmap redirection To: varun shrivastava <[EMAIL PROTECTED]> On Fri, 22 Feb 2008, varun shrivastava wrote: > 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 just use the latest patch by me for the moment. there will be updated versions once that is committed. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: visible window rectangle in pixmap redirection
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 <[EMAIL PROTECTED]> 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 (af
Re: visible window rectangle in pixmap redirection
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
visible window rectangle in pixmap redirection
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: - 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? - 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? - 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(). thanks for the patch in the first place. i think the above are the last major issues left before pixmap redirection can go in. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
