Re: gtk_widget_draw()
On Thu, 2010-08-26 at 15:13 -0500, Federico Mena Quintero wrote: On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote: Just keep in mind that it's very normal for text ink to leak out of the allocation area. So even if the draw-border property is removed, we should eventually figure out how to handles these. But widgets are supposed to request a size that will fit their ink_rect, correct? That's what extents logical is for, isn't it? ie, something that is more or less constant in size for a given font, regardless of the particular glyphs being drawn, right? AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On 08/18/10 07:58, Matthias Clasen wrote: We are just about to remove that style property, called GtkWidget::draw-border, since it has some overhead, and nobody ever used it. Just keep in mind that it's very normal for text ink to leak out of the allocation area. So even if the draw-border property is removed, we should eventually figure out how to handles these. In vte for example, we always draw one extra row/column of glyphs outside of the expose are, just in case they leak into the expose area. Doing this generally would be very expensive... unless... One way to do this would be: There's some damage tracking api that has been proposed for inclusion to cairo. Using that and custom api (for non-cairo drawing, etc), the widgets can mark their ink rect during expose. Then gtk can maintain an ink rect as well as the usual logical allocation. Then we just need to intersect the expose region with the ink rects to determine which childs to expose. The order of exposing siblings will be significant in such a world though. behdad See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote: Just keep in mind that it's very normal for text ink to leak out of the allocation area. So even if the draw-border property is removed, we should eventually figure out how to handles these. But widgets are supposed to request a size that will fit their ink_rect, correct? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Sat, 2010-08-21 at 00:01 -0400, Havoc Pennington wrote: On the Clutter front I'd still like to see the ClutterBackend replaceable at runtime so you could basically put GTK in there or your compositing manager in there, and avoid Clutter's attempts to do its own Xlib things. That'd be a nice step forward. one of the goals for 1.6 is to have a better Backend split between Clutter and COGL, since both have low-level interactions with the windowing system (e.g. COGL really needs to process events for handling the GLX_texture_pixmap and the GLX_swap_event extensions). one of the end results would be to have the windowing system part really generic and have extension points for init-time selection of the windowing system backend[0]. this would actually allow a GDK backend to be easily written; then clutter-gtk could depend on it, and embedding GTK widgets inside Clutter would be (relatively) easier than the current implementation - which is already possible anyway. another piece of the puzzle, and another step in the right direction, is to make a COGL backend for Cairo; this would allow high quality, hardware accelerated 2D rendering and avoid the current render in an image surface and upload it to a GL texture situation. the work to be able to make GTK render directly to a cairo_t* is, in this regard, necessary - especially for theme engines. the GtkSizeRequest interface in 2.90/3.0 is already making the Clutter and GTK+ size negotiation match; if we could manage to get a frame-based redraw cycle in GTK+, or to slave the GTK+ redraw cycle to the Clutter master clock, we could also use the animation API from Clutter directly into GTK+ itself. All I'm saying is I think there's a useful direction to move in that really doesn't require a huge rewrite. I generally agree, and I think that we can have a solid roadmap by the time of the hackfest to actually make this stuff happen during the 3.0 cycle. ciao, Emmanuele. +++ [0] Clutter obviously need to maintain its own backends, since it's actually also targeting platforms that are not GDK-capable (by design or requirement). it doesn't mean that a GDK backend could not be in-tree or be the default. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, All of these changes sound really awesome. On Sat, Aug 21, 2010 at 7:02 AM, Emmanuele Bassi eba...@gmail.com wrote: this would actually allow a GDK backend to be easily written; then clutter-gtk could depend on it, and embedding GTK widgets inside Clutter would be (relatively) easier than the current implementation - which is already possible anyway. Nice! another piece of the puzzle, and another step in the right direction, is to make a COGL backend for Cairo; this would allow high quality, hardware accelerated 2D rendering and avoid the current render in an image surface and upload it to a GL texture situation. the work to be able to make GTK render directly to a cairo_t* is, in this regard, necessary - especially for theme engines. Nice again! I think it's clear GL (via COGL) and not Cairo needs to be the bottom of the stock, though sadly for a while at least it's not practical to make this the default/mandatory. the GtkSizeRequest interface in 2.90/3.0 is already making the Clutter and GTK+ size negotiation match; if we could manage to get a frame-based redraw cycle in GTK+, or to slave the GTK+ redraw cycle to the Clutter master clock, we could also use the animation API from Clutter directly into GTK+ itself. Oh yes indeed. (would love to see the master clock redraw loop sort of down in the GDK or COGL or somewhere layer) [0] Clutter obviously need to maintain its own backends, since it's actually also targeting platforms that are not GDK-capable (by design or requirement). it doesn't mean that a GDK backend could not be in-tree or be the default. Exactly (and for GTK also, it will need a stack without GL in there for forseeable future for example). But I think there are natural abstraction points, that sort of make sense and clean things up _anyway_, that make everything play well together. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 12:10 -0400, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis p...@linuxaudiosystems.com wrote: sometimes i hate gmail keybindings ... so, to finish what i was saying ... in my mind, a canvas does two things: 1) composites together the result of a variety of different objects drawing themselves/ it does this paying attention to the area of a window that needs to be redrawn according to external information (e.g. expose events) and the internal state of the canvas (e.g. invalidated state in something that is displayed within the window). the primary information required to do this is the extent of each object. most canvases would also take z-order stacking into account when ordering the redrawing, but this isn't actual critical to this basic model of what is happening. 2) event distribution i.e. finding the correct object to deliver an event to in the first instance, and then propagating that to other objects until the event is handled according to some kind of logical rule or rules. it seems to me that GTK (like some other toolkits) is increasingly converging on this model, without any specific awareness that this is likely where it all ends up. Gtk+ has always followed this model though, it just now does it more internally where it previously relied on some support from the windowing system. Generally people have a more detailed requirements when they call things a canvas, like being able to view the object/hierarchies transformed, and perhaps in multiple places. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a suave arachnophobic jungle king fleeing from a secret government programme. She's a warm-hearted nymphomaniac socialite with an MBA from Harvard. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Fri, 2010-08-20 at 03:09 +0200, Benjamin Otte wrote: On Thu, Aug 19, 2010 at 10:08 AM, Alexander Larsson al...@redhat.com wrote: The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. I think this is a crucial question we need to answer about future GTK/GDK: Who should be responsible for chaining up to children? (Note that this question is not just interesting for drawing, but also relevant for event handling.) Currently everybody does at most half of this job: GDK does it for windows, GTK does it for drawing on no-window widgets (with gtk_container_propagate_expose()). GtkWindow does it for key presses. Well, no-window widgets merely handle drawing, not events, those are still handled by gdk (via input-only windows). The reason for no-window widgets are twofold: 1) Allow transparent widgets, i.e. those that paint over their parent. 2) Avoid use of visible native windows as much as possible, as these cause ugly resizing behaviour. Although it also gets you: 3) Somewhat easier to code draw-only widgets. (i.e. no need for realize/unrealize or any other window handling) 2 is fixed with csw and 1 is simple to add. With a remove of no-window widgets we make container widgets simpler, but widgets like in 3 somewhat harder. I think that can be fixed by better default realize/unrealize implementations though. So, imho no-window widgets removal is an obvious candidate for simplification when we have the chance. In my ideal world, the containers are responsible for bubbling up drawing commands and events. For gtk_widget_draw(), this is pretty much a requirement. Otherwise we'd need to duplicate the GDK functionality into that function (just lik gtk_widget_get_snapshot() does now). Also, relegaing this job to Gtk allows much more flexibility in creating widgets because one is not bound by the limitations of GDK as one translates events oneself. So things like Coverflows get possible. A different semantics for events (maybe the bubble down then up again style from the web world) is a nice idea. However it would be a break in event handling that is quite large. Additionally it puts a lot of load on widgets, as each widget now have the full responsibility to manage the event semantics required for its children (deliver enter/leave events with the right detail and crossing mode, know of global state such as grabs and foucs, etc). This is the kind of stuff it took me a year to fix for the gdk even propagator, not something you want to push on widget authors. I think the offscreen window model we have for event translation is much simpler and something mere mortals could possibly get right. It lets you define additional parent-child links and coordinate transformations, the rest is handled by gdk. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fast talking Jewish jungle king with a winning smile and a way with the ladies. She's a vivacious gypsy former first lady from beyond the grave. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Fri, Aug 20, 2010 at 5:15 AM, Alexander Larsson al...@redhat.com wrote: Gtk+ has always followed this model though, it just now does it more internally where it previously relied on some support from the windowing system. GTK has historically not composited separately drawn surfaces together, and has historically had no z-axis. But yes, the fact that its moving closer and closer to this model is undeniable, and I'm really excited and glad about that. Hence my original email. What puzzles me is the mental effort that appears to go into avoiding what to me seems like the inevitable conclusion of this evolution: GTK-as-scene-graph. We inherited a very particular mindset from the early X toolkits, and its taking us a very long time to shake off their fundamental model of what a toolkit *is*. I just think it would be cool if instead of accidentally lurching ever closer to GTK-as-scene-graph, we just made that a more explicit end goal, sort of as Havoc did in his slides from 2 years ago. Generally people have a more detailed requirements when they call things a canvas, like being able to view the object/hierarchies transformed, and perhaps in multiple places. Hence Havoc's use of the term scene graph which i think is about equally ambiguous but without the particular connotations that you refer to. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Fri, 2010-08-20 at 09:00 -0400, Paul Davis wrote: What puzzles me is the mental effort that appears to go into avoiding what to me seems like the inevitable conclusion of this evolution: GTK-as-scene-graph. We inherited a very particular mindset from the early X toolkits, and its taking us a very long time to shake off their fundamental model of what a toolkit *is*. A new toolkit would probably this without hesitation. The cause for the mental effort is that we already have a toolkit with hundreds of apps and libraries that use it. We need to have some level of compatibility with it, or people are gonna be very pissed. Additionally doing such a redesign has a lot more risk. We know the strenghts and weaknesses of the current gtk+. A large redesign may seem right initially, but show up significant problems after a while, so such a project would need a much longer development period where it takes shape. If I were to do something like that I'd keep gtk3 approximately as it now takes shape (i.e. cleanup but mostly compatible). Then create a completely new toolkit with a different name, based on the gtk stack (i.e. cairo, glib, gio, pango, etc). This is kinda what clutter does, , although clutter is not really a full toolkit (no toplevel handling, no file dialogs, no printing, no dnd, etc, etc). I don't think its worth it though. Even when reusing the lower parts of the stack we're talking many man-years of work, and I think the linux desktop could spend that effort better on other things. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a hate-fuelled flyboy romance novelist with acid for blood. She's a warm-hearted renegade bounty hunter with a flame-thrower. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Alexander Larsson wrote: On Fri, 2010-08-20 at 09:00 -0400, Paul Davis wrote: What puzzles me is the mental effort that appears to go into avoiding what to me seems like the inevitable conclusion of this evolution: GTK-as-scene-graph. We inherited a very particular mindset from the early X toolkits, and its taking us a very long time to shake off their fundamental model of what a toolkit *is*. A new toolkit would probably this without hesitation. The cause for the mental effort is that we already have a toolkit with hundreds of apps and libraries that use it. We need to have some level of compatibility with it, or people are gonna be very pissed. Additionally doing such a redesign has a lot more risk. We know the strenghts and weaknesses of the current gtk+. A large redesign may seem right initially, but show up significant problems after a while, so such a project would need a much longer development period where it takes shape. If I were to do something like that I'd keep gtk3 approximately as it now takes shape (i.e. cleanup but mostly compatible). Then create a completely new toolkit with a different name, based on the gtk stack (i.e. cairo, glib, gio, pango, etc). This is kinda what clutter does, , although clutter is not really a full toolkit (no toplevel handling, no file dialogs, no printing, no dnd, etc, etc). I don't think its worth it though. Even when reusing the lower parts of the stack we're talking many man-years of work, and I think the linux desktop could spend that effort better on other things. If I may suggest a couple of things here... It's not necessary to answer the question of whether gtk is or is-not a 'canvas' (or scene-graph or whatnot). That can vary widely depending on just what your point of view is, and/or what the actual internal implementation details are, or how far down one wants to look. What's important is what functionality it could expose via its public api and how to best implement such efficiently (and for legacy issues, I suppose you'd want to do so without too much breakage). When it comes to the question of the desirability of some notion of a canvas (or scene-graph if you like), it should be clear that whatever such a thing might be it's best if it were a local rather than global construct, ie. it's far more flexible if gtk *had* a canvas widget than for it to *be* a canvas. Now, just what might a useful canvas notion be? Well, I'd suggest the rather simple one of a gtk container widget which imposes no constraints on the positioning/geometry of its child widgets. What further properties it might allow is dependent on what you want (likely wanted are compositing transforming of the child widgets, etc). Along with such a widget, it might also be useful for gtk to have various gfx widgets. These are 'widgetized' versions of whatever gfx primitives the underlying gfx rendering model has. So for example with the standard 2d vgfx model you'd have say line, rectangle,... widgets, and of course the generic path widget. Additionally, a raster-image gfx widget and possibly various kinds of text related ones might also be desirable. Such gfx widgets would likely best be implemented as atomic (leaf-like) widgets and of course as efficiently as possible. Of course one can then use such gfx widgets anywhere within gtk not just with the canvas widget, and conversely one can have any widget as a child of the canvas widget not just the 'gfx' ones. With just this setup (and what's already been proposed re cairo, etc) you can get most of the modern, rich app functionality that people want. Of course one needs more, things like an anim framework, other flexible layout containers, etc. But apart from implementation details involving such things as whether or not only top-level widgets should correspond to display-system windows, or other issues such as new event propagation schemes, it may not be too great a change. Note that this kind of setup exists in some well-known gui toolkits... in particular in Adobe's new flex4 and MS's wpf/silverlight. In any case... just some thoughts. All the best, Jose. Notre Dame Certificates 100% Online Programs in Negotiation Leadership and Mgmt. Enroll Today! http://thirdpartyoffers.juno.com/TGL3141/4c6f1e148dadf7ad776st05duc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Fri, Aug 20, 2010 at 8:32 PM, Jose Gonzalez jose_...@juno.com wrote: When it comes to the question of the desirability of some notion of a canvas (or scene-graph if you like), it should be clear that whatever such a thing might be it's best if it were a local rather than global construct, ie. it's far more flexible if gtk *had* a canvas widget than for it to *be* a canvas. i think this is fundamentally wrong and fundamentally at odds with the evolution of GTK and with the evolution of other toolkits on both X Window and other platforms. put differently, and to paraphrase something said about unix: those who don't understand scene graphs are condemned to reinvent them, poorly. so no, i don't agree that this is clear, and in fact, i don't even agree that its correct. the gains from having a single drawing model and single event propagation model that extended from the simplest elements of the toolkit up the the most complex (probably the treeview at this time) are huge. Now, just what might a useful canvas notion be? Well, I'd suggest the rather simple one of a gtk container widget which imposes no constraints on the positioning/geometry of its child widgets. What further properties it might allow is dependent on what you want (likely wanted are compositing transforming of the child widgets, etc). we have such widgets, but they are hampered by the fact that existing GTK widgets are rooted in the fundamental GTK axiom that widgets themselves do not overlap. but it really doesn't matter: this doesn't address the question of whether or not the internal model of GTK reflects its long term trajectory toward a scene graph model. and i really mean this. look at everything that has happened with the fundamental internals of GTK over the 10+ years that i've used it for application development, and they all either trend toward a scene graph model or have no relationship at all to this evolution (e.g. input methods). i would almost be to wager a bet: if GTK is not substantially implemented as a scene graph within 4 years, i'll eat the hat that i still haven't eaten from my bet that JACK (http://jackaudio.org/) could not work well on Windows :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, On Fri, Aug 20, 2010 at 5:22 PM, Alexander Larsson al...@redhat.com wrote: If I were to do something like that I'd keep gtk3 approximately as it now takes shape (i.e. cleanup but mostly compatible). Then create a completely new toolkit with a different name, based on the gtk stack (i.e. cairo, glib, gio, pango, etc). This is kinda what clutter does, , although clutter is not really a full toolkit (no toplevel handling, no file dialogs, no printing, no dnd, etc, etc). I don't think its worth it though. Even when reusing the lower parts of the stack we're talking many man-years of work, and I think the linux desktop could spend that effort better on other things. I think the path to this is really pretty clear. It's already been shown by Clutter and HippoCanvas among others, both of which embed GTK widgets and have been used to make real apps. Hell, other examples are WebKit, XUL, even GnomeCanvas. You do the scene graph lib and you use GTK for the hard widgets and toolkit stuff. There's a model where you put GtkWidget inside the canvas, and there's a model where you put the canvas inside a GtkWidget, or do both. Whichever way, GTK can be used for things like input methods and DND and toplevel windows. There's a path of gradual refactoring to strip duplication between the Clutter/HippoCanvas/whatever thing and GTK itself, most of which makes nice sense anyway because for both GtkWidget and subclasses, and ClutterActor and subclasses, and HippoCanvasItem and subclasses, or whatever, all those things are better off if they are just a canvas and minimize entanglements with the window-system-ish stuff. Saying completely new toolkit leads to reimplementing really big hard things such as: keymap handling, input methods, themes, TreeView, TextView, even Entry, DND, etc. etc. all of which is very solid in GTK+ already. It should be possible to get to scene graph without redoing any of that. Actually, it is possible. It's been done in specific canvasy-thing-using apps. On the Clutter front I'd still like to see the ClutterBackend replaceable at runtime so you could basically put GTK in there or your compositing manager in there, and avoid Clutter's attempts to do its own Xlib things. That'd be a nice step forward. I don't think any of this is truly hard or even a ton of work. What's a ton of work is the point where you try to go GTK+ 4 and force one of the specific scene graphy things. Especially if that's done before some of the tough problems have de facto answers already working. But in terms of practical benefits to apps you can get really really far by just refactoring GTK+ and Clutter and whatever to play nice with each other by avoiding these assumptions about who owns the window system abstraction, master clock paint loop, layout idle, etc. - and to some extent, keeping scene graphs from creeping up into trying to become full toolkits is helpful, if instead GTK's facilities such as themes and input methods can work well for non-widgets, that's a big win. Lots of these problems are already solved in a hacky way, just not in a clean way. One concrete thing GTK can do is work with interfaces rather than GtkWidget for APIs such as DND or input methods or whatever it is, so that an actor/item class can implement the interface too. A harder, but nice thing GTK could do is to work toward GDK being less GTK-specific; this cleanup work definitely is on that path I'd say. But think about Clutter basically targeting GDK, and on the flip side (and blocking on a future where GL can be assumed), think about GTK making use of COGL. A way to think about it is that GTK could become several distinct features, possibly in separate libs: window system abstraction; little-to-do-with-widget/actor/item stuff such as input methods, keyboard handling, GtkAction, etc. ; GtkWidget/GtkContainer widget core (the widgety scene graph); and finally a collection of widgets. I'd add to that, GL system abstraction (i.e. COGL). Oh, and in one of those buckets should be the paint loop (master clock) or nobody can do decent animations. All I'm saying is I think there's a useful direction to move in that really doesn't require a huge rewrite. In fact I'd say a new toolkit is dumb. The evolutionary approach has already been slowly going there and people cobble stuff together. If you look at GTK+ and Clutter there may well be a simple practical problem: no module to put shared code in. Kind of like when freedesktop.org was started, it was just to solve ok, gnome and kde want to share code that does xyz, where the hell would we even keep that code... Dunno. I guess I'm just thinking that the old model of so many different things making up a toolkit is kinda fading, we've seen important GTK chunks shedding down into Cairo and Pango and GLib and gdk-pixbuf already, and I'd only expect that to continue, as GTK gradually evolves toward only being one specific scene graph system among several, the others mostly less widgety
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 11:13 -0500, Federico Mena Quintero wrote: On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can glow around a widget] There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Hmm. I just think it's overkill to complicate the GdkWindow abstraction just for themes' sake. Correct me if I'm wrong, but I think you imagine the glow-around-a-button to actually have allocated space around the button * +--+ * +--+ * |button| * |button| * +--+ * +--+ while I'm imagining that the glow actually overlaps anything around the widget ** * +--+ +*-+ * |button| |*utton| * +--+ +*-+ ** The latter is doable if the theme creates a temporary window as a child of the toplevel, on top of all the other subwindows. Themes can't generally modify the window hierarchy or have other state like this. They just affect the drawing of the widget. [Do we just lack the don't clip flag on windows] To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. I guess InputOnly windows are trivial when we get the transparent windows we've been talking about - you just never draw to them. Old apps could still use them to get events. We already support InputOnly windows fine in csw. Getting rid of no-window widgets would be trivial in GTK+, but it would break a lot of code that already uses that trick and does all the coordinate-munging on its own... maybe we should make no-window mean you won't know it, but you really get a cairo_t with a transformation relative to your parent widget? That way you still have to make the changes to take a cairo_t instead of a GdkWindow (for the draw() method), but you don't have to change your delicate code that deals with coordinates. The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a benighted arachnophobic librarian with a robot buddy named Sparky. She's a mistrustful red-headed bodyguard fleeing from a Satanic cult. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, Aug 19, 2010 at 10:08 AM, Alexander Larsson al...@redhat.com wrote: The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. I think this is a crucial question we need to answer about future GTK/GDK: Who should be responsible for chaining up to children? (Note that this question is not just interesting for drawing, but also relevant for event handling.) Currently everybody does at most half of this job: GDK does it for windows, GTK does it for drawing on no-window widgets (with gtk_container_propagate_expose()). GtkWindow does it for key presses. In my ideal world, the containers are responsible for bubbling up drawing commands and events. For gtk_widget_draw(), this is pretty much a requirement. Otherwise we'd need to duplicate the GDK functionality into that function (just lik gtk_widget_get_snapshot() does now). Also, relegaing this job to Gtk allows much more flexibility in creating widgets because one is not bound by the limitations of GDK as one translates events oneself. So things like Coverflows get possible. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 16:04 -0500, Federico Mena Quintero wrote: On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote: Additionally I was thinking one could specify a border on the window such that for clipping purposes and calculation of what has to be repainted we grow the window by the border width, while for events and the rest we use the normal size. This makes it easy to implement themes that have a more organic look, for instance having a glow on an active button that extends outside the button without affecting events, etc. Do you need that? Can't you create a separate window overlaid on your button, and paint the glow on *that* one? (The window would extend past the normal window's edge; it would probably need the toplevel to be its parent so the glow can go over everything, etc. - but it sounds doable like that...) There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Who uses reparenting, anyway? Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. I don't think reparenting is needed for toolbar items and detachable docks - unless X forces you to do it to get really smooth painting. Plug/socket is special anyway, as you need to cross into the actual window system. Yeah, but the way you do this is via gdk. It is the bridge to the native windowing system. Just ignoring that is not gonna help us. Event masks affect more than performance though. They are combined to decide which window gets each event. For instance, if you have a window somewhere with a bunch of child hierarchies, and the window has the event mask for mouse motion, then it will get mouse motion even over the child windows, unless the child window sets mask for mouse motion too. So, just sending everything everywhere is not a solution. Ah, OK :) I guess this is due to X not having event callbacks and the boolean means whether the callback handled the event thing... Such callbacks would be very costly in an client-server over-network model, since there will be many roundtrips per event. So, apart from the general pending cleanup, are we just lacking the don't clip flag discussed above for transparent windows? To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a bookish moralistic stage actor on the hunt for the last specimen of a great and near-mythical creature. She's a strong-willed French-Canadian barmaid trying to make a difference in a man's world. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 3:37 AM, Alexander Larsson al...@redhat.com wrote: There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. a solution. We are just about to remove that style property, called GtkWidget::draw-border, since it has some overhead, and nobody ever used it. See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? In my mind a canvas does two things: 1. Retained drawing. You draw something and you get a handle back to it so that you can modify it (move it, recolor it, etc.). GDK doesn't do retained drawing; it does direct drawing where you draw something but you have no way to modify it afterwards. 2. Hit detection. You get events relative to the objects that you drew. This is a lot more sophisticated than something happened inside this rectangular window :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 11:49 AM, Federico Mena Quintero feder...@ximian.com wrote: On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? In my mind a canvas does two things: 1. Retained drawing. You draw something and you get a handle back to it so that you can modify it (move it, recolor it, etc.). GDK doesn't do retained drawing; it does direct drawing where you draw something but you have no way to modify it afterwards. 2. Hit detection. You get events relative to the objects that you drew. This is a lot more sophisticated than something happened inside this rectangular window :) in my mind, a canvas does two things: 1) composites together the result of a variety of different objects drawing themselves, most likely with z-axis ordering. it does 2) event distribution ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis p...@linuxaudiosystems.com wrote: sometimes i hate gmail keybindings ... so, to finish what i was saying ... in my mind, a canvas does two things: 1) composites together the result of a variety of different objects drawing themselves/ it does this paying attention to the area of a window that needs to be redrawn according to external information (e.g. expose events) and the internal state of the canvas (e.g. invalidated state in something that is displayed within the window). the primary information required to do this is the extent of each object. most canvases would also take z-order stacking into account when ordering the redrawing, but this isn't actual critical to this basic model of what is happening. 2) event distribution i.e. finding the correct object to deliver an event to in the first instance, and then propagating that to other objects until the event is handled according to some kind of logical rule or rules. it seems to me that GTK (like some other toolkits) is increasingly converging on this model, without any specific awareness that this is likely where it all ends up. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can glow around a widget] There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Hmm. I just think it's overkill to complicate the GdkWindow abstraction just for themes' sake. Correct me if I'm wrong, but I think you imagine the glow-around-a-button to actually have allocated space around the button * +--+ * +--+ * |button| * |button| * +--+ * +--+ while I'm imagining that the glow actually overlaps anything around the widget ** * +--+ +*-+ * |button| |*utton| * +--+ +*-+ ** The latter is doable if the theme creates a temporary window as a child of the toplevel, on top of all the other subwindows. [Do we just lack the don't clip flag on windows] To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. I guess InputOnly windows are trivial when we get the transparent windows we've been talking about - you just never draw to them. Old apps could still use them to get events. Getting rid of no-window widgets would be trivial in GTK+, but it would break a lot of code that already uses that trick and does all the coordinate-munging on its own... maybe we should make no-window mean you won't know it, but you really get a cairo_t with a transformation relative to your parent widget? That way you still have to make the changes to take a cairo_t instead of a GdkWindow (for the draw() method), but you don't have to change your delicate code that deals with coordinates. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? See http://log.ometer.com/2008-03.html#7 perhaps. Another way to think of canvas (different than in the above slide deck), is what I call just a canvas vs. toolkit stuff - toolkit stuff is all the global singletons, the GApplication, the main loop, the window system abstraction layer. A really nice thing about HippoCanvas was that the canvas items didn't really see above themselves to parent items, or most of all they didn't poke at toplevel windows or a stage or a global backend thingy such as a display. Instead HippoCanvas is totally recursive - events get to leaf items by being sent to parent items that then forward to the leaf items, to draw the whole screen you just draw the root item, etc. This then makes it very easy to be in that gtk_widget_draw() type of world where you can draw items to other contexts such as to print them. I think both GTK 2.x and Clutter have fairly suboptimal code where there's a good bit of leakage of the global window system goo into the actors/widgets, and part of this thread is about mopping that up. A nice thing about having actors and widgets separate from all the toolkit stuff is that it makes it a good bit simpler to mix two different kits together. Anyway that's one aspect of this, and the other I think is more in the slides I linked to, which is that canvas items are generally more flexible than widgets (have transforms, don't have to be a rectangle, etc.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 12:27 PM, Havoc Pennington h...@pobox.com wrote: Hi, On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? See http://log.ometer.com/2008-03.html#7 perhaps. Yes, absolutely. I've seen this before and I think it probably helped get me thinking along these lines. I think it doesn't quite go far enough, but something that combines these ideas with what has already happened regarding CSW and drawing methods moves things a good bit of the way. I also find it interesting that in some sense, Wayland is just another scene graph, but at a different level (able to eat X Window in a single bite-kind-of-level). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, 2010-08-16 at 21:36 -0400, Allin Cottrell wrote: On Mon, 16 Aug 2010, Alexander Larsson wrote: - Benjamin Otte o...@gnome.org wrote: Here's an email detailing my thought process for what I want to do with rendering in the master branch following the rendering-cleanup merge. It's mostly a brain dump, so treat it as such. So, I read this thread and thought about it a bit (not a lot though, obviously this whole thing needs a lot of careful thought). Its a complex area, and while I share your enthusiasm for many of the changes I think in some places it might oversimplify things. Anyway, lets start on a positive side with things where we are wildly in agreement. Getting rid of GdkPixmap seems like a good think. Its not used a lot in the current rendering-cleanup branch... Wait a minute: Not used a lot(!) App developers are in limbo here. Not so long ago we were told that if our apps compiled OK with all the appropriate DISABLE_DEPRECATED flags with the latest stable versions of the libraries (GTK and friends) we'd be fine for GTK+ 3. There will be a new gtk 2.x release with all the stuff being removed in gtk3 being deprecated, and it will have any required new functions added, like gdk_window_create_similar_surface() which can be used to create offscreen cairo surfaces to be used as GdkPixmap replacement. Then Benjamin came along with phase 1 of his GDK cleanup and that seemed sensible, though not without problems for app developers. I've now cleaned up my app so that it does not use GdkGC if GTK is new enough. But my replacement code for GdkGC uses GdkPixmap -- and now we can't have that either?! Switching from GdkPixmap to using a cairo x surface is not a large change though. Its mainly in how you construct it. The actual use of it is almost all the same. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish coffee-fuelled shaman haunted by an iconic dead American confidante She's an elegant mute cab driver descended from a line of powerful witches. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, 2010-08-12 at 20:48 +0200, Benjamin Otte wrote: EOG uses this to good effect, for example - scaling an image is expensive, so it only scales the areas that absolutely need to be repainted. Cairo does that automatically. On the GPU, too. So I suppose EOG doesn't yet upload the pixbuf to a native cairo surface and uses that for rendering? Just FYI, I have been playing a bit with this, in order to replace current's eog code for handling with the scaling/rendering and rely completely on cairo; but it is clearly noticeably that this becomes really slow when the image is over certain dimensions, say 4096×4096. In any other case, performance is *really* great. The patches are in bug https://bugzilla.gnome.org/show_bug.cgi?id=626795 , if you care to see. Claudio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson al...@redhat.com wrote: [...] Just doing this is a great cleanup and simplification of gdk and the backends, which is clearly a good step towards further work. Great. This is what I've been hacking on in the rendering-cleanup branch (yes, you cannot make it die, even by merging it) since it was merged last time. I do not inted to touch any GdkWindow internals in that branch until it's merged again. The branch right now focusses on getting rid of GdkPixmap and providing suitable replacements. More on that in a separate mail though. However, the next step, getting rid of the wrappers/impls and restructuring the window class hierarchy is not really right imho. Having impls be a separate object type is quite nice for CSW, it models pretty well the situation where GdkWindow are the client side things, and GdkWindowImpls are the native part that GdkWindows draw in, etc. It also matches the dynamic status of nativeness. I.e. a window can get a native window when needed rather than having to do this upfront. If nativeness was encoded in the typesystem things like that just wouldn't work. The biggest problem for me when reading the GdkWindow code is that I have no idea what a window is. So I have a hard time understanding the code and if what it does is sane. - Does a GdkWindow mirror a window provided by the windowing system? Obviously no, because offscreen windows do not own a windowing system window and csw windows do grab onto the native parent's window. So the relationship between GdkWindows and X Windows is 1:N (where N can be 0). - Does a GdkWindow have a matching Cairo surface? Well, kinda, but csw windows share the surface with of the native window, so when drawing to it, we need to clip before we draw. - Is a GdkWindow an implementation detail or available in the public API? Again, it depends. If you have a GdkWindowImplFoo, it's private, otherwise it's public. Can I even call the same (internal or public) functions on these two types of windows? - Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly you can restack and reparent windows fine, but stuffing a toplevel into an offscreen window does not work at all. - What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will it change type? Should it? - Who's responsible for what? Who decides when to repaint a window? Is it the same for offscreen windows? Who creates damage events? - Can windows be translucent? Should they be? - Is a GdkWindow the only way to get enter/leave events to widgets? Do widget authors know these thing? - What do we do with event masks? I learned yesterday that widgets without EXPOSURE_MASK don't get their background cleared. Is that documented? Or should that even be the case? Do we even need event masks? - Shoud every widget have its own window now that we have lightweight client-side windows? Or should almost no widget have a window because we can synthethically create all the events widgets need? Do we have a list for widget authors somewhere for when they want to create their own window? Note that I don't describe the current state of things in GTK2, I can look that up in the code if I have to. I'm more interested in how things should be. Similarly a problem is encoding things like toplevel/subwindowness in the typesystem (i.e. GdkSubwindow or GdkToplevel). A subwindow is a subwindow purely based on where its in the hierarchy, which is easily changed with gdk_window_reparent. This means windows can go from toplevels and back at runtime. But there are operations that do not make sense at all on a non-toplevel window. Like setting the icon or the title. And I'd argue that it's confusing for widget implementors that they need to think about this stuff when creating a window for their widget. For offscreen windows, a lot more of the window operations don't make sense. This part of things has been very concrete stuff, now we get to the more abstract parts about rendering using cairo only. First of all I must say your description is kinda handwavy in the details. For instance, its not at all obvious how multi-window widgets are supposed to render themselves, or how the window hierarchy is traversed while rendering. I think in retrospect, that that is mostly related to the question outlined above about what a GdkWindow is and what it does. It's hard to be concrete if you have no idea about the underlying design. ;) Secondly, while I think your description of a no-exposes cairo_t-only rendering system sounds very nice I fear that it is to simple to handle everything a full featured toolkit will meet in practice. People will want to put all kinds of weird stuff inside a Gtk window, including things like: OpenGL rendered stuff, Xv magic, socket/plug X embedding, embedding things like a flash plugin or old motif plugins in a browser, etc. There is just no way you can take things like these and put them transformed on a pdf
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote: On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson al...@redhat.com wrote: [...] However, the next step, getting rid of the wrappers/impls and restructuring the window class hierarchy is not really right imho. Having impls be a separate object type is quite nice for CSW, it models pretty well the situation where GdkWindow are the client side things, and GdkWindowImpls are the native part that GdkWindows draw in, etc. It also matches the dynamic status of nativeness. I.e. a window can get a native window when needed rather than having to do this upfront. If nativeness was encoded in the typesystem things like that just wouldn't work. The biggest problem for me when reading the GdkWindow code is that I have no idea what a window is. So I have a hard time understanding the code and if what it does is sane. Yeah, this is simultaneously very simple and very hard to explain. The simple version is its behaves like if there was a X window there, except some minor changes. Of course, the hard version includes having to read the full Xlib specification and knowing all the minor historic ways that gdk arbitrarily differs from the X behavior. Clearly this is not a great setup. I definitely would not propose something like this were we to start over with a new toolkit. However, its what we have, and even minor changes to the semantics (like tiny event ordering issues or minute grab event property differences) cause weird and very hard to track down bugs. I know, I had to track them all down... Additionally, while GdkWindows are complex and underdocumented they are not really something that most users of Gtk+ ever touch, which limits the problem. - Does a GdkWindow mirror a window provided by the windowing system? Obviously no, because offscreen windows do not own a windowing system window and csw windows do grab onto the native parent's window. So the relationship between GdkWindows and X Windows is 1:N (where N can be 0). - Does a GdkWindow have a matching Cairo surface? Well, kinda, but csw windows share the surface with of the native window, so when drawing to it, we need to clip before we draw. This is one of the major deficiencies with csw actually. I requested sub-surface support in cairo multiple times and got positive feedback, but it just hasn't happened yet. Ideally we should use that so that we can avoid hacks like gdk_cairo_reset_clip(). - Is a GdkWindow an implementation detail or available in the public API? Again, it depends. If you have a GdkWindowImplFoo, it's private, otherwise it's public. Can I even call the same (internal or public) functions on these two types of windows? All GdkWindows visible to external parties are public API. The impls are internal stuff that behave in somewhat weird ways, but again, this is not something normal people see. - Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly you can restack and reparent windows fine, but stuffing a toplevel into an offscreen window does not work at all. With offscreen windows its more like a forest than a tree, with the limit that no window with a native window can be a child of an offscreen. - What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will it change type? Should it? I think it does now, at least if CHILD goes to TOPLEVEL. I dunno what the perfect behaviour would be. In a GdkToplevel world such a reparent operation would have to just fail. But what if the reparenting happens anyway? For instance when the parent GtkSocket X window dies and your GtkPlug becomes a toplevel? - Who's responsible for what? Who decides when to repaint a window? Is it the same for offscreen windows? Who creates damage events? - Can windows be translucent? Should they be? Right now they are typically not, but you can enable the optional composite feature to make them translucent. This is sort of a hack that was added to do some features that can now be done with offscreen widget embedding. - Is a GdkWindow the only way to get enter/leave events to widgets? Do widget authors know these thing? GdkWindows are the main source of events, without them you never get any events. The features that windows give are: * Something you can render on and display * Invalid region tracking (internal and from the window system) * Implicit clipping based on the environment of the window * Easy scrolling of window hierarchies * Event generation - What do we do with event masks? I learned yesterday that widgets without EXPOSURE_MASK don't get their background cleared. Is that documented? Or should that even be the case? Do we even need event masks? They should get the background of the GdkWindow cleared, but of course there will be no expose event so any widget-specific background will not be drawn. - Shoud every widget have its own window now that we have lightweight client-side windows? Or should almost no widget
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
The biggest problem for me when reading the GdkWindow code is that I
have no idea what a window is. So I have a hard time understanding the
code and if what it does is sane.
One pattern we see a lot is when widgets want to paint themselves on
their parent container's background, but still receive events. They are
NO_WINDOW widgets, which means I want to share my parent's window, and
then they also create INPUT_ONLY windows to catch events.
This is a very useful pattern. Such widgets are basically saying:
- Just give me a nicely-prepared surface to draw on (i.e. with the
parent's contents already drawn)
- And let me catch events, too.
The funny thing is that not only non-square widgets like labels do
this; buttons also do this for aesthetic purposes.
I think it seems sane to move to a model where
1. The only native windows (with an XID) are toplevels, with a few
exceptions (see below),
2. All subwindows are all GDK-side abstractions. They define a clipping
region and a coordinate system. See below for transparency issues.
3. The exception is when you need a native window to do funky stuff
(OpenGL, plug/socket, xv, etc.). These (sub)windows are understood to
be limited - you may not be able to transform them and such.
The interesting part is (2), or what happens with subwindows.
Non-square widgets that want to paint to their parent's background would
still benefit from having a transparent window to paint on - this
would give you an already-prepared surface (with whatever the parent
painted), a clipping region and a coordinate system. That is, GtkLabel
wouldn't have to clip the text itself and add allocation-{x,y} all the
time.
Square widgets that completely cover their area are of course trivial to
implement in that model - they would just overwrite their parent's
contents with their own. I don't know if we want to be able to avoid
painting the parent's regions that we *know* will be completely
obscured. Think of a white text area over a gradient window background
- drawing that gradient may be expensive and so you certainly want to
paint only the areas that will *not* be the white text area... or maybe
not, if you can just ask the GPU to draw the whole gradient.
Do we need a window-need_parent_background flag? I.e. the paint the
parent first, don't clip to the subwindow flag?
I don't think these transparent windows should store any contents at
all to composite them later. GDK doesn't store window contents, and
starting to do that sounds painful. Keep subwindows just as an
abstraction for clipping/coordinates/initial-background.
With the model above, the repaint cycle looks pretty much like the
current one - you paint recursively, and you just set the clip region
(or not) based on a subwindow's need_parent_background flag.
- Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly
you can restack and reparent windows fine, but stuffing a toplevel
into an offscreen window does not work at all.
- What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will
it change type? Should it?
This is the core of Alex's argument for keeping the impls separate, I
think. GdkWindow exposes a public API (with a few leaks such as
gimme_the_native_window_id()); the internal impls switch in and out as
you reparent things.
Who uses reparenting, anyway?
Restacking our abstracted subwindows should be trivial; you just repaint
them in order.
- Can windows be translucent? Should they be?
See above.
- Is a GdkWindow the only way to get enter/leave events to widgets? Do
widget authors know these thing?
If they don't know offhand, they learn pretty fast :) Basically, having
a window is the *only* way to get events. Whether you do it with an
InputOutput or an InputOnly window depends on each particular widget.
- What do we do with event masks? I learned yesterday that widgets
without EXPOSURE_MASK don't get their background cleared. Is that
documented? Or should that even be the case? Do we even need event
masks?
Clearing the background or not depends on the hypothetical
is-this-window-transparent flag that we discussed above.
Event masks are an X-ism, I think... I really don't know if they matter
much with local connections (except maybe to save context switches);
they may definitely help in remote connections. Something tells me that
Owen will know more about this from when he was profiling GTK+'s X
stream.
- Shoud every widget have its own window now that we have lightweight
client-side windows? Or should almost no widget have a window because
we can synthethically create all the events widgets need? Do we have a
list for widget authors somewhere for when they want to create their
own window?
If we move to the model I described above, then it should be pretty
clear that all widgets can have windows (for convenience) and yet be
able to draw themselves as they wish.
But there are operations that
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 13:43 -0500, Federico Mena Quintero wrote:
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
The biggest problem for me when reading the GdkWindow code is that I
have no idea what a window is. So I have a hard time understanding the
code and if what it does is sane.
One pattern we see a lot is when widgets want to paint themselves on
their parent container's background, but still receive events. They are
NO_WINDOW widgets, which means I want to share my parent's window, and
then they also create INPUT_ONLY windows to catch events.
This is a very useful pattern. Such widgets are basically saying:
- Just give me a nicely-prepared surface to draw on (i.e. with the
parent's contents already drawn)
- And let me catch events, too.
The funny thing is that not only non-square widgets like labels do
this; buttons also do this for aesthetic purposes.
Yeah, they do it to avoid the window resize being asynchronous with
respect to the repainting, etc, causing ugly looking resizes.
I think it seems sane to move to a model where
1. The only native windows (with an XID) are toplevels, with a few
exceptions (see below),
2. All subwindows are all GDK-side abstractions. They define a clipping
region and a coordinate system. See below for transparency issues.
3. The exception is when you need a native window to do funky stuff
(OpenGL, plug/socket, xv, etc.). These (sub)windows are understood to
be limited - you may not be able to transform them and such.
This is exactly the current model with client side windows.
The interesting part is (2), or what happens with subwindows.
Non-square widgets that want to paint to their parent's background would
still benefit from having a transparent window to paint on - this
would give you an already-prepared surface (with whatever the parent
painted), a clipping region and a coordinate system. That is, GtkLabel
wouldn't have to clip the text itself and add allocation-{x,y} all the
time.
Yes. I've long thought about having something like this. Then we could
just drop no-window widgets. This might make widget rendering a bit more
regular as there is at least a simple relationship between a window and
a widget (each window belongs to a single widget, one widget may have
multiple windows).
This is very similar to input-only window really. Its kinda inbetween.
Input only windows only do the events, transparent windows do the
rendering and clipping, but render the parent first without clipping to
the transparent childs (like it doesn't clip to input-only children).
Additionally I was thinking one could specify a border on the window
such that for clipping purposes and calculation of what has to be
repainted we grow the window by the border width, while for events and
the rest we use the normal size. This makes it easy to implement themes
that have a more organic look, for instance having a glow on an active
button that extends outside the button without affecting events, etc.
Square widgets that completely cover their area are of course trivial to
implement in that model - they would just overwrite their parent's
contents with their own. I don't know if we want to be able to avoid
painting the parent's regions that we *know* will be completely
obscured. Think of a white text area over a gradient window background
- drawing that gradient may be expensive and so you certainly want to
paint only the areas that will *not* be the white text area... or maybe
not, if you can just ask the GPU to draw the whole gradient.
Well, the white text area would just not be transparent and then the
drawing in the parent would be clipped to the child just like now.
Also, for the current no-window widget this is what we do already
anyway.
Do we need a window-need_parent_background flag? I.e. the paint the
parent first, don't clip to the subwindow flag?
Not sure what you mean. We need a single flag is this window
transparent. If it is that means:
1) It does not add to its parents clip-region
2) When redrawing it we must draw all parents and lower stacked siblings
before drawing it.
This is the core of Alex's argument for keeping the impls separate, I
think. GdkWindow exposes a public API (with a few leaks such as
gimme_the_native_window_id()); the internal impls switch in and out as
you reparent things.
Who uses reparenting, anyway?
Dnd of toolbars items, detachable docks, putting plugs in sockets, etc.
- What do we do with event masks? I learned yesterday that widgets
without EXPOSURE_MASK don't get their background cleared. Is that
documented? Or should that even be the case? Do we even need event
masks?
Clearing the background or not depends on the hypothetical
is-this-window-transparent flag that we discussed above.
Event masks are an X-ism, I think... I really don't know if they matter
much with local connections (except maybe to save context switches);
they may definitely
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote: [Widgets with an InputOnly window for events] Yeah, they do it to avoid the window resize being asynchronous with respect to the repainting, etc, causing ugly looking resizes. Oh, I thought they did it to get the parent's background. So there are multiple reasons to do this :) This is exactly the current model with client side windows. Perfect, so we are on the same page and I just need to re-understand the current state of GDK :) Additionally I was thinking one could specify a border on the window such that for clipping purposes and calculation of what has to be repainted we grow the window by the border width, while for events and the rest we use the normal size. This makes it easy to implement themes that have a more organic look, for instance having a glow on an active button that extends outside the button without affecting events, etc. Do you need that? Can't you create a separate window overlaid on your button, and paint the glow on *that* one? (The window would extend past the normal window's edge; it would probably need the toplevel to be its parent so the glow can go over everything, etc. - but it sounds doable like that...) Do we need a window-need_parent_background flag? I.e. the paint the parent first, don't clip to the subwindow flag? Not sure what you mean. We need a single flag is this window transparent. If it is that means: 1) It does not add to its parents clip-region 2) When redrawing it we must draw all parents and lower stacked siblings before drawing it. Yes, that's exactly what I mean :) A single flag that does exactly that. Who uses reparenting, anyway? Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. I don't think reparenting is needed for toolbar items and detachable docks - unless X forces you to do it to get really smooth painting. Plug/socket is special anyway, as you need to cross into the actual window system. [Anyway, this was about the impls being separate - if we keep reparenting, then impls may need to stay... no idea.] Event masks affect more than performance though. They are combined to decide which window gets each event. For instance, if you have a window somewhere with a bunch of child hierarchies, and the window has the event mask for mouse motion, then it will get mouse motion even over the child windows, unless the child window sets mask for mouse motion too. So, just sending everything everywhere is not a solution. Ah, OK :) I guess this is due to X not having event callbacks and the boolean means whether the callback handled the event thing... So, apart from the general pending cleanup, are we just lacking the don't clip flag discussed above for transparent windows? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
- Benjamin Otte o...@gnome.org wrote: Hi, Here's an email detailing my thought process for what I want to do with rendering in the master branch following the rendering-cleanup merge. It's mostly a brain dump, so treat it as such. So, I read this thread and thought about it a bit (not a lot though, obviously this whole thing needs a lot of careful thought). Its a complex area, and while I share your enthusiasm for many of the changes I think in some places it might oversimplify things. Anyway, lets start on a positive side with things where we are wildly in agreement. Getting rid of GdkPixmap seems like a good think. Its not used a lot in the current rendering-cleanup branch. The only thing I see that is slightly problematic is windows backgrounds. I'm not sure what we should replace this with? One approach is to use X cairo pattern rather than pixmaps. Pixmap backgrounds are heavily used in themes atm, but that may change with the new theming api. Also, pixmap background in windows are mainly used to get nice initial repaint behaviour (no flashing before expose finished) which is less important in a modern composited world. Another obvious thing is folding GdkDrawable into GdkWindow. With the removal of pixmaps and the gc ops this truly is a useless class. Disallowing multiple calls to being_paint_region() and using a window as source while drawing also sounds like pure wins in terms of dropping complexity with no real loss in useful operations. Just doing this is a great cleanup and simplification of gdk and the backends, which is clearly a good step towards further work. However, the next step, getting rid of the wrappers/impls and restructuring the window class hierarchy is not really right imho. Having impls be a separate object type is quite nice for CSW, it models pretty well the situation where GdkWindow are the client side things, and GdkWindowImpls are the native part that GdkWindows draw in, etc. It also matches the dynamic status of nativeness. I.e. a window can get a native window when needed rather than having to do this upfront. If nativeness was encoded in the typesystem things like that just wouldn't work. Similarly a problem is encoding things like toplevel/subwindowness in the typesystem (i.e. GdkSubwindow or GdkToplevel). A subwindow is a subwindow purely based on where its in the hierarchy, which is easily changed with gdk_window_reparent. This means windows can go from toplevels and back at runtime. Even if its possible to perhaps enforce things like this from the gdk typesystem it is not really representative to how the actual underlying abstraction (i.e. X windows or win32 HWND) really work, so its gonna cause a bunch of pain fighting the system, for a relatively small gain (approximately nobody uses gdkwindow apis anyway, as its too low-level). There is still some class hierarchy cleanup that can be done with the new drawable-free situation though. I.e. We can have something like: Public classes: GdkWindow Internal Classes: GdkNativeWindow | (replaces GdkWindowImplIface, could maybe be a public type? | maybe not ideal name due to offscreen subclass...) |- GdkOffscreenWindow |- GdkWindowX11 |- GdkWindowQuartz |- GdkWindowWin32 This part of things has been very concrete stuff, now we get to the more abstract parts about rendering using cairo only. First of all I must say your description is kinda handwavy in the details. For instance, its not at all obvious how multi-window widgets are supposed to render themselves, or how the window hierarchy is traversed while rendering. Secondly, while I think your description of a no-exposes cairo_t-only rendering system sounds very nice I fear that it is to simple to handle everything a full featured toolkit will meet in practice. People will want to put all kinds of weird stuff inside a Gtk window, including things like: OpenGL rendered stuff, Xv magic, socket/plug X embedding, embedding things like a flash plugin or old motif plugins in a browser, etc. There is just no way you can take things like these and put them transformed on a pdf surface. We have to expose a more raw expose system. Also, a straight single paint function isn't ideal for e.g printing a widget, or scaling it up a gui. Its quite common for widgets to have offscreen pixmaps with stuff that are pre-rendered that are just blasted out when drawing. These things would generally be allocated when the widget is realized by making surfaces similar to the window (ie x pixmaps of the same size/depth). A more general method would have separate callbacks (somewhat similar to realize/unrealize) for preparing to draw on some surface/scale factor that let you create such surfaces for the right target, letting you keep vector info when things are drawn on e.g. a pdf surface. Nevertheless, for all standard widgets this is a good model that would be nice to use. So, lets try to make it work. As a basis, lets say all drawing are done inside a (explicit
Re: gtk_widget_draw()
On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote: This is awesome stuff, Benjamin. I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr); One thing I'd definitely like to have is the region-to-expose. Many times people have started with oh, I'll just paint everything every time, only to find later that this is too slow. Then they go and make use of the expose-rectangle or the finer expose-region, and things magically become fast. EOG uses this to good effect, for example - scaling an image is expensive, so it only scales the areas that absolutely need to be repainted. I don't know if you can get the clip path set on a cairo_t, but even if you can, getting a path is not ideal... a region made out of rectangles, like GdkRegion, seems more generally useful. 3) Resolution independence. A cairo_scale (cr, 2, 2) before calling gtk_widget_draw() smoothly scales widgets to twice the size. Of course, event translation and all that fun is needed, too, but the rendering part is there. Good drawing functions do their best to align things to the pixel grid, if it exists. Does Cairo let you know the device's resolution, or something that lets you know if the current transformation is pixel-aligned? (If I tell my resolution-independent desktop to scale itself by 1.73 times for my aging eyes, by using the friendly zoom factor slider that it provides, then I'd still like crisp widgets as best as possible.) 4) Make the window's surface gettable You might want to use a window as a source in drawing operations or do other stuff with it (like calling cairo_surface_create_similar() for the pixmap replacement) so this needs to be available. Arguably, Hmmm, is this related to GDK_NO_EXPOSE events? Such as you would get on the destination window if you gdk_draw_drawble() with the source being partially obscured. (Copying from window to window seems anachronistic these days, anyway... and if you can simply tell another widget/window to gtk_widget_draw() itself into our own temporary surface, you don't need cross-window blits.) 7) Improve repaint semantics Something like disallowing multiple being_paint_region() calls and disallowing the use of windows as a source while a repaint is happening sound very desirable to me. The code that circumvents these issues is quite extensive and buggy and noone uses these features anyway. Also, the Paintable interface should probably be folded back into GdkWindow, too. gdk_window_begin_paint_region() is just a convenient way of saying give me a temporary buffer with magic coordinates. We could very well have windows keep a stack of Cairo surfaces (or just a stack of clipping regions + transformations, etc.) that get flattened when the last gdk_window_end_paint() is called. Or maybe just make those functions basically be wrappers for cairo_save/restore() plus some clipping and coordinate-changing. Somewhat related to that is gdk_window_scroll(). Or does CSW handle that magically? You *definitely* want scrolling to be done as much in hardware as possible, at least for blitting the already-exposed region. You only want to repaint the scrolled-in area at any time. 11) Remove the expose_event from GtkWidget Now that the whole repaint handling is done in the draw signal, there's no more need for expose events. The semantics are somewhat different, as draw signals don't correspond 1:1 to expose events. But I think that change shouldn't matter for all practical purposes. And if you need it, you can just connect to the event signal of the GdkWindow. This seems very clean - native windows send you events; widgets translate that to draw signals as appropriate. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-10 at 01:59 +0200, Benjamin Otte wrote: [Widgets that own multiple windows] My current idea on how to implement it is to give the widgets a hint as to wether they are repainting a window or wether they are painting to something else. Something like gdk_cairo_get_current_window() which would return the currently invalidating GdkWindow or NULL. That would basically replace event-window and then all you need to do is check that the order of the draw calls is the window's stacking order and you're all set. If gtk_widget_draw(w, cr) really means paint thyself, then we need to make widgets with subwindows have no extra work to do. Let me throw some ideas: - If you have an event signal in GdkWindow, like you proposed, then we can make widgets responsible for connecting to their subwindows. In theory the (client-side) window system will send those signals in Z order. We may need a hint to say send me an expose for this parent window even if a child window obscures it for if you want to have transparent windows - you want the parent to paint its background, and then the child to overlay its stuff. - We can have gtk_widget_register_subwindow(w, window), called by widget implementations. Then the stock GtkWidget code magically connects to expose on those GdkWindows, and calls ::draw() as appropriate. I guess this is roughly similar to moving gdk_window_set_user_data() into GTK rather than GDK. Then the draw method would be called with a clip region set to the appropriate subwindow, or something. I like the second idea better. The summary is that even widgets with subwindows should really paint everything to whatever is on the cairo_t passed to draw(). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, Aug 12, 2010 at 7:27 PM, Federico Mena Quintero feder...@ximian.com wrote: - If you have an event signal in GdkWindow, like you proposed, then we can make widgets responsible for connecting to their subwindows. In theory the (client-side) window system will send those signals in Z order. We may need a hint to say send me an expose for this parent window even if a child window obscures it for if you want to have transparent windows - you want the parent to paint its background, and then the child to overlay its stuff. - We can have gtk_widget_register_subwindow(w, window), called by widget implementations. Then the stock GtkWidget code magically connects to expose on those GdkWindows, and calls ::draw() as appropriate. I guess this is roughly similar to moving gdk_window_set_user_data() into GTK rather than GDK. Then the draw method would be called with a clip region set to the appropriate subwindow, or something. If you have transparent windows, you want two things: 1) Drawing the parent window does not draw to the child window 2) Updating the child window does not require drawing parent windows first. (1) would be overkill, because we might end up drawing everything twice. (2) is important because you might want to use the translucent window as a source for some drawing operations elsewhere and if that'd automatically draw the stuff below it first, you couldn't do that. What complicates the matters here is that in some cases it's the windowing system that composites and in some cases it's GDK that does. And to make matters more interesting, there's different windowing systems with different ideas on how stuff should work. There is also the possibility of declaring all native windows opaque and have client-side windows not send expose events at all. This would have 2 advantages: 1) It'd work fine when we'd just called the draw function of child widgets, though it'd change how we handle it right now. 2) We wouldn't need to do all those mad clipping hacks we currently do. The proper decision also depends on wether we want to support using any window as a source for drawing operations. Currently GDK does not allow doing that. Again, just random thoughts, Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, Aug 12, 2010 at 7:15 PM, Federico Mena Quintero feder...@ximian.com wrote: One thing I'd definitely like to have is the region-to-expose. Many times people have started with oh, I'll just paint everything every time, only to find later that this is too slow. Then they go and make use of the expose-rectangle or the finer expose-region, and things magically become fast. The way you'd do it in cairo is something like this: gdk_cairo_rectangle (cr, widget-allocation); cairo_clip (cr); cairo_clip_extents (cr, x1, y1, x2, y2); if (rect_is_empty (x1, y1, x2, y2)) return; So far this has proven enough for all the things I've done. There's also cairo_copy_clip_rectangle_list() if you want finer-grained control, but I never needed that. EOG uses this to good effect, for example - scaling an image is expensive, so it only scales the areas that absolutely need to be repainted. Cairo does that automatically. On the GPU, too. So I suppose EOG doesn't yet upload the pixbuf to a native cairo surface and uses that for rendering? Good drawing functions do their best to align things to the pixel grid, if it exists. Does Cairo let you know the device's resolution, or something that lets you know if the current transformation is pixel-aligned? Yes, it provides you with all the facilities you need to transform to and from device units. See cairo_user_to_device(), cairo_user_to_device_distance() and the device_to_user versions. (If I tell my resolution-independent desktop to scale itself by 1.73 times for my aging eyes, by using the friendly zoom factor slider that it provides, then I'd still like crisp widgets as best as possible.) And you also want smooth scaling when you drag that slider, so please no jumps from 1 pixel wide borders to 2 pixel wide ones, I know... ;) gdk_window_begin_paint_region() is just a convenient way of saying give me a temporary buffer with magic coordinates. We could very well have windows keep a stack of Cairo surfaces (or just a stack of clipping regions + transformations, etc.) that get flattened when the last gdk_window_end_paint() is called. Or maybe just make those functions basically be wrappers for cairo_save/restore() plus some clipping and coordinate-changing. Yeah, I was thinking about using cairo_push/pop_group() internally, but then there's backends like GL or Quartz that are double buffered. Somewhat related to that is gdk_window_scroll(). Or does CSW handle that magically? You *definitely* want scrolling to be done as much in hardware as possible, at least for blitting the already-exposed region. You only want to repaint the scrolled-in area at any time. I've still not seen anybody provide a real-world use case for it, so I'm skeptical about that assertion, but so far this is the only code in GDK that still uses XCopyArea directly. For that reason alone, I'd like to get rid of it. (Interestingly, it is the only function in all of X that allows self-copies. Xrender explicitly forbids it.) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Sun, Aug 8, 2010 at 8:07 PM, Benjamin Otte o...@gnome.org wrote: Hi, Here's an email detailing my thought process for what I want to do with rendering in the master branch following the rendering-cleanup merge. It's mostly a brain dump, so treat it as such. I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr); That function will draw the given widget to the given cairo_t, no matter what kind of cairo_t you hand it I think I can subscribe to that. It sounds like a nice goal. 3) Resolution independence. A cairo_scale (cr, 2, 2) before calling gtk_widget_draw() smoothly scales widgets to twice the size. Of course, event translation and all that fun is needed, too, but the rendering part is there. I fear that this glosses over considerable amounts of complication. How will input and output translation be kept in sync ? 4) New backends. It's easy to render to anything that we can create a cairo surface for. So integration with Clutter or other GL applications becomes a lot easier. But...a backend still needs to have input handling and all that other fun stuff. I can that putting cairo surfaces between gdk and widgets will make widget implementations slightly nicer, and will make it easy to render a widget to anything. But gdk itself does not seem to benefit much from it, directly. So how do I get there: [ Long list elided ] Your list seems to largely consist of gdk refactoring. Which is not bad in itself. But a lot of the complication in the current gdk csw implementation comes from the replicating X semantics. So my question is: do you propose that we give up on doing this, with the argument that 'cairo is good enough' ? And if so, what are the semantics that we are replacing it with ? Having that spelled out clearly will no doubt be useful to future gdk backend authors. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, On Sun, Aug 8, 2010 at 8:07 PM, Benjamin Otte o...@gnome.org wrote: I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr); That function will draw the given widget to the given cairo_t, no matter what kind of cairo_t you hand it, no matter wether it's an actual X window and the drawing is due to an expose event or if it's an image surface for a screenshot or even if it's a PDF for printing. How would we handle widgets that currently have multiple windows and draw different things to each one (i.e. the expose handler is looking at the window in the expose event). For example GtkTextView Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 9, 2010 at 1:03 PM, Morten Welinder mort...@gnome.org wrote: Here's an email detailing my thought process for what I want to do with rendering in the master branch following the rendering-cleanup merge. It's mostly a brain dump, so treat it as such. Assuming you managed to get all that done, how much time do you think it would be reasonable to set aside for upgrading applications? IMHO, anything less than a few months (as measured from the last significant API break to Gnome 3) is disrespectful of application writers. Remember that gtk2 doesn't cease to exist the moment we release 3.0, so you can really take as much time as you want. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
hi Havoc, On Mon, 2010-08-09 at 12:46 -0400, Havoc Pennington wrote: How would we handle widgets that currently have multiple windows and draw different things to each one (i.e. the expose handler is looking at the window in the expose event). For example GtkTextView I think we should just fix these. It seems like the only GtkWidgets that posess GdkWindows ought to be toplevels (windows, popups, etc) and GtkPlug/GtkSocket. That said, I really have no concept about the amount of work required. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, On Mon, Aug 9, 2010 at 3:57 PM, Ryan Lortie de...@desrt.ca wrote: I think we should just fix these. It seems like the only GtkWidgets that posess GdkWindows ought to be toplevels (windows, popups, etc) and GtkPlug/GtkSocket. Subwindows do have a function though (events, clipping, scrolling). I think with text view you'd have to sort of replicate that functionality with a new API to replace gtk_text_view_get_window(), gtk_text_view_set_border_window_size(), etc. Right now the API is get a window to draw to and get events on and it would have to become something like a callback where you get a cairo context to draw to, and I'm not sure about the events. GtkSourceView would be one heavily-affected codebase if there are changes here. gdk_window_scroll() is probably fairly easy to get rid of... _if_ you don't care about avoiding a full repaint. If you want to only repaint the new area - that seems a bit tricky to me. Maybe client-side windows already solved it, I don't know. It's just something that stands out to me from this direction of work as I don't know offhand exactly what I'd do about it that's all, so I was curious. I'm all in favor of this work. (One reason is, I'd love to see any downsides to just using GTK widgets inside Clutter removed; starting over on all the hard widgets, input methods, etc. on top of Clutter loses an awful lot of effort and functionality imo.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 9, 2010 at 6:46 PM, Havoc Pennington h...@pobox.com wrote: How would we handle widgets that currently have multiple windows and draw different things to each one (i.e. the expose handler is looking at the window in the expose event). For example GtkTextView I'm not entirely sure yet. I want to guarantee two semantics: 1) The stuff looks correct on screen. This one is a no-brainer. It should also be fast. 2) Calling gtk_widget_draw() draws all child widgets, even if they have custom windows. This is necessary, because nobody will like just getting a grey box when the contained widgets all have custom windows. And I don't like the whole just-paint-all-windows-one-after-another code in gtk_widget_snapshot() at all. My current idea on how to implement it is to give the widgets a hint as to wether they are repainting a window or wether they are painting to something else. Something like gdk_cairo_get_current_window() which would return the currently invalidating GdkWindow or NULL. That would basically replace event-window and then all you need to do is check that the order of the draw calls is the window's stacking order and you're all set. Though I guess the exact implementation would depend on our changes to GDK and the way we treat csw in GTK 3. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 9, 2010 at 6:22 PM, Matthias Clasen matthias.cla...@gmail.com wrote: 3) Resolution independence. A cairo_scale (cr, 2, 2) before calling gtk_widget_draw() smoothly scales widgets to twice the size. Of course, event translation and all that fun is needed, too, but the rendering part is there. I fear that this glosses over considerable amounts of complication. How will input and output translation be kept in sync ? No idea. I'm just hoping the new stuff makes it possible on the rendering side of things. Then we just need to fix the rest of GDK and GTK, and we're there! In all seriousness, I have no idea what's missing for resolution independence and suspect a lot. But there should be a lot less things missing on the output side after I'm done. 4) New backends. It's easy to render to anything that we can create a cairo surface for. So integration with Clutter or other GL applications becomes a lot easier. But...a backend still needs to have input handling and all that other fun stuff. I can that putting cairo surfaces between gdk and widgets will make widget implementations slightly nicer, and will make it easy to render a widget to anything. But gdk itself does not seem to benefit much from it, directly. Of course. What you get is a free pass on writing the output side of things - as Cairo can render anything using fallback as long as you implement draw-to-window and -fetch-from-window. You'll still need to code window handling, event handling etc. But from looking at the code I already deleted in the rendering-cleanup branch, there's a few thousand lines of code less to write per backend already. You will not get backends for free yet - though you might get the rendering for free. ;) Your list seems to largely consist of gdk refactoring. Which is not bad in itself. But a lot of the complication in the current gdk csw implementation comes from the replicating X semantics. So my question is: do you propose that we give up on doing this, with the argument that 'cairo is good enough' ? And if so, what are the semantics that we are replacing it with ? Having that spelled out clearly will no doubt be useful to future gdk backend authors. Cairo and GdkWindow are orthogonal in a lot of places. In particular, CSW have roughly nothing to do with Cairo. However, a lot of the complexity inside the GdkWindow code comes from making pixmaps and windows share a common base class and the impl/wrapper split. And now that we separate windows from drawables, we can clean that up and simplify the code and APIs. I think that's what most of my ideas aim at. I don't think I want to change semantics. I don't even think I know the code well enough (yet? ;)) to have definite ideas on how to do that. However, if we're already doing all this cleanup work, it might be a good idea to rethink semantics. What I'm hoping is that with a cleaner code base we'll find some very obvious cases where a slight change can improve thhings a lot, and then we can fix those. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 9, 2010 at 10:17 PM, Havoc Pennington h...@pobox.com wrote: GtkSourceView would be one heavily-affected codebase if there are changes here. I did not mention this explicitly anywhere yet, so I'll do it here: My goal is to have all my changes minimize the effects on code that is equivalent to GTK, i.e. the usual widgets people code, like graphs or docks or even the simple ones like web browsers, canvasses or textviews. For their use cases, a transition to new APIs should ideally be possible using search/replace, but should not include huge refactorings to new semantics. To give an example: I think it's ok to make people change the name of their paint function from foo_expose to foo_draw and remove the two lines cr = gdk_cairo_create (event-window) and cairo_destroy(cr); in that function. However, requiring widgets to rethink their whole GdkWindow-using tricks is not a good idea. That doesn't mean it won't be necessary - porting from gdk draw API to Cairo is not always straightforward - but I'm trying very hard to minimize that work. (One reason is, I'd love to see any downsides to just using GTK widgets inside Clutter removed; starting over on all the hard widgets, input methods, etc. on top of Clutter loses an awful lot of effort and functionality imo.) I'm not sure if we can achieve that, or if we even should, but in my dream world, someone is going to write a GDK backend using clutter. And then a GdkWindow is just another ClutterActor. That would probably give us the best of both worlds. How and when we get there and if GTK will be called MX by then is left to the imagination of anyone involved. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote: So, that's a rough list of ideas I have currently. I have no idea if I get all of this done for 3.0 and in what order I'm going to tackle these problems It all sounds utterly brilliant. ++ Changing the object hierarchies is a bit of a yellow flag for me; for our purposes (and this is squarely in the my problem, not yours, but hey category) they are ABI and hard to change post 3.0 I realize your list was mostly a brainstorm, but do you think you could order it by * things that could happen before GTK 3.0 * things that can happen after GTK 3.0 my thought being that if you can get the API ABI changes [and again I'm thinking about class hierarchies, and new signals count too] in to 2.90 then we can accommodate them in the 3.0 ABI break, even if some (much) of it isn't live yet. expose-event I assume you're not thinking of taking that out before 3.0? [ie, it'd be cool 'n all, and we'll be getting rid of lots of other things deprecated, but that's kinda a monster, no?] AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
