Re: Deprecate GdkGC?
On Sat, 2005-12-03 at 03:28 +0100, milosz derezynski wrote: http://beep-media-player.org/~mderezynski/cairo.txt Fantastic. I've started adding DocBook markup to this, and will commit it to the GTK+ docs when I'm done with that. Milosz, if you make changes to your text, could you please forward the diffs to me? That will make it easy to integrate the changes into the marked-up version. Thanks for writing this up! Federico chapter id=gtk-migrating-Cairo chapterinfo author firstnameMilosz/firstname surnameDerezynski/surname affiliation address email[EMAIL PROTECTED]/email /address /affiliation /author /chapterinfo titleMigrating from the GDK drawing functions to Cairo/title para Since version 2.8, GTK+ uses the ulink url=http://www.cairographics.org;Cairo/ulink library as its preferred drawing backend, in contrast to the the older drawing functions in acronymGDK/acronym (GTK+ Drawing Kit). /para para When running GTK+ under X11, GDK is tightly based on the Xlib drawing API. X11 core graphics are very poor, and entirely pixel based. For example, at the time X11 was designed, the designers attempted to follow the specification for wide lines in the Adobe Red Bookfootnote para FIXME: bibliography /para /footnote. But that specification turned out to not be what Adobe actually implemented; it is computationally very difficult. Moreover, it has extremely ugly results, producing lumpy lines, rendering wide lines essentially useless to applications. /para para Even in the X11 design meetings, there was an intent to augment the core 2D graphics for X, but it was not expected this would take 15 years! /para para In other windowing systems, GDK uses the system's default drawing functions. These are generally similar to the Xlib drawing functions: they provide non-antialiased primitives, and have very little or no support for sophisticated drawing operations such as affine transformations or using a transparency channel. /para para Cairo has a number of advantages: /para itemizedlist listitem para It is device-independent. Cairo can render to Xlib drawables or the windows on other windowing systems, or client-side offscreen buffers. Additionally, support is planned for rendering to PostScript and PDF documents, as well as using hardware acceleration through OpenGL. /para /listitem listitem para Being able to render to Postscript and/or PDF documents also makes it very easy to use Cairo to render documents for printing. GTK+ will have a printing API in the future, with the graphics primitives based on Cairo. /para /listitem listitem para Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension). /para /listitem listitem para Cairo supports antialiasing, transparency channels, gradients, affine transformations, and features that GDK simply doesn't have as it is basically a wrapper over Xlib. /para /listitem /itemizedlist !-- Below this point, nothing is marked up yet -- 2. GDK drawing primitives+GdkGC vs. Cairo+GdkCairo 2.1 GdkGC GDK uses GdkGCs. A GdkGC is a Graphics Context. A Graphics Context holds information about the current foreground color, background color, a clipping mask, a current set font, basically, it holds values that will or rather might be used for the next drawing operation using this particular GdkGC; might, because not all operations need all GdkGC values, e.g. a line draw doesn't need the font information that the GdkGC has stored as one of it's values. This fact exactly is the negative of a GdkGC: the fact that it is not an atomic object. It holds information about a line cap style, about a font and a clipping mask, but not all of them are used in all of your drawing operations, and hence you are forced to either constantly modify the GC, or create new GdkGCs that fit the values for your next drawing operation. 2.2 Cairo With Cairo, a concept such as a GC does not exist. You set the values like the color or pattern, line cap and join styles, or a clipping mask before the next drawing operation. While this might at the very first glance look like a drawback, because you can just re-use a GC for subsequent drawing operation with the same parameters, it actually proves more efficient to hold these particular values inside some part of your application that you could call graphics management (just to coin a name), and acquire them trough your internal API calls before doing a Cairo drawing operation. This might be for example a specific color palette. Please don't confuse this with the term palette conventionally used
Re: Deprecate GdkGC?
Well, i volunteer for this. I have used cairo extensively for coding bmpx and i'm going to get to a very good point in documenting at least all the equivalents of gdk_draw_*()Federico: In which format should i write this, anything that would be preferred? PS: I've created a bug (http://bugzilla.gnome.org/show_bug.cgi?id=322996) and added a patch that adds a function gdk_cairo_set_source_drawable (), it's just 2 function calls but i think it's more logical to the API user and makes for a more consistent API, and _gdk_drawable_ref_cairo_surface () is private anyway On 12/2/05, Federico Mena Quintero [EMAIL PROTECTED] wrote: On Thu, 2005-12-01 at 22:50 +0100, milosz derezynski wrote: I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors and apps still do this:gdk_gc_set_clip_rectangle (widget-style-black_gc, my_rect); gdk_draw_pixbuf (widget-window, widget-style-black_gc, my_pixbuf, ...);gdk_gc_set_clip_rectangle (widget-style_black_gc, NULL);I mean, that would still work.But if we schedule GCs for deprecation, we need really really good docs on how to migrate everything to Cairo.Actually, we have needed those since Cairo became the preferred drawingAPI instead of gdk_draw_*()...Any takers?Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
On 12/2/05, Federico Mena Quintero [EMAIL PROTECTED] wrote: On Fri, 2005-12-02 at 09:43 +0100, milosz derezynski wrote: Well, i volunteer for this. I have used cairo extensively for coding bmpx and i'm going to get to a very good point in documenting at least all the equivalents of gdk_draw_*() Federico: In which format should i write this, anything that would be preferred?Excellent!You'll make me owe you a beer.The GTK+ documentation is written in DocBook ( www.docbook.org).Thesources are in gtk+/docs/reference/gtk.Look for the migrationchapters there.If you don't know DocBook, don't worry.Just write your docs as a textfile and I'll add the markup for you. ok thxi'll go start writing then :) PS: I've created a bug (http://bugzilla.gnome.org/show_bug.cgi?id=322996) and added a patch that adds a function gdk_cairo_set_source_drawable (), it's just 2 function calls but i think it's more logical to the API user and makes for a more consistent API, and _gdk_drawable_ref_cairo_surface () is private anywayThis is to use a pixmap as a repeating pattern, or something like that,right?Federico Well this is meant to be an analogon to gdk_cairo_set_source_pixbuf ()..Thinking about the docs i thought roughly of the equivalent operations of gdk_draw_*() with Cairo, and there is no real direct equivalent of gdk_draw_drawable(), so this function is meant to do replace it, but there are several implications to that patch which matthias and cworth pointed out to me, so i don't think this patch can hold as it is. However i do think that for the sake of a consistent API there should be such a function (with this name) and there should be no 'exception' in which when someone wants to draw a drawable has to acquire cairo surfaces etc.. (I think in all cases of Cairo equivalent operations to gdk_draw_*() no one has to deal with the surfaces really, just with the cairo_t* cairo context itself, so this would be a real exception). There was a discussion on #gtk+ about this but i'm sorry i can't fully repeat it right now :(In any case though matthias pointed this bug out to me with special attention to owen's comment on it: http://bugzilla.gnome.org/show_bug.cgi?id=318805 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
Ok i've started writing it, there are a few FIXMEs which i might resolve myself during writing, gotta ask cworth about it.The document is located and will be for the time being (unless we convert it to doxygen/gtk-doc in the meantime) here: http://beep-media-player.org/~mderezynski/cairo.txtMiloszOn 12/2/05, milosz derezynski [EMAIL PROTECTED] wrote: I just saw you've added it to the 2.10 API freeze, well i'm not sure it (the patch) can be kept as it is but i strongly favor that we have a function with this name that does the same that gdk_cairo_set_source_pixbuf () does (so that you can use cairo operations to draw a drawable onto a drawable). On 12/2/05, milosz derezynski [EMAIL PROTECTED] wrote: On 12/2/05, Federico Mena Quintero [EMAIL PROTECTED] wrote: On Fri, 2005-12-02 at 09:43 +0100, milosz derezynski wrote: Well, i volunteer for this. I have used cairo extensively for coding bmpx and i'm going to get to a very good point in documenting at least all the equivalents of gdk_draw_*() Federico: In which format should i write this, anything that would be preferred?Excellent!You'll make me owe you a beer.The GTK+ documentation is written in DocBook ( www.docbook.org).Thesources are in gtk+/docs/reference/gtk.Look for the migrationchapters there.If you don't know DocBook, don't worry.Just write your docs as a textfile and I'll add the markup for you. ok thxi'll go start writing then :) PS: I've created a bug (http://bugzilla.gnome.org/show_bug.cgi?id=322996) and added a patch that adds a function gdk_cairo_set_source_drawable (), it's just 2 function calls but i think it's more logical to the API user and makes for a more consistent API, and _gdk_drawable_ref_cairo_surface () is private anywayThis is to use a pixmap as a repeating pattern, or something like that,right?Federico Well this is meant to be an analogon to gdk_cairo_set_source_pixbuf ()..Thinking about the docs i thought roughly of the equivalent operations of gdk_draw_*() with Cairo, and there is no real direct equivalent of gdk_draw_drawable(), so this function is meant to do replace it, but there are several implications to that patch which matthias and cworth pointed out to me, so i don't think this patch can hold as it is. However i do think that for the sake of a consistent API there should be such a function (with this name) and there should be no 'exception' in which when someone wants to draw a drawable has to acquire cairo surfaces etc.. (I think in all cases of Cairo equivalent operations to gdk_draw_*() no one has to deal with the surfaces really, just with the cairo_t* cairo context itself, so this would be a real exception). There was a discussion on #gtk+ about this but i'm sorry i can't fully repeat it right now :(In any case though matthias pointed this bug out to me with special attention to owen's comment on it: http://bugzilla.gnome.org/show_bug.cgi?id=318805 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Deprecate GdkGC?
Shouldn't GdkGC be deprecated now that we have cairo contexts? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors.I am currently unaware of whether the style engines access them directly but i'd rather think they do, so this would require the style engines to 1) only use the GdkColors of the style and (while we're at) 2) add an alpha value to GdkColor like the r/g/b ones already are (?) Sounds like a long process of deprecation by policy, but i agree that GdkGCs don't make much sense anymore if at all.MiloszOn 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote:Shouldn't GdkGC be deprecated now that we have cairo contexts? Murray Cumming[EMAIL PROTECTED]www.murrayc.comwww.openismus.com___ gtk-devel-list mailing listgtk-devel-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors. So, I guess that should be ported too. In general, deprecation doesn't mean that you may not use it. Deprecation is n't breaking. I am currently unaware of whether the style engines access them directly but i'd rather think they do, so this would require the style engines to 1) only use the GdkColors of the style and (while we're at) 2) add an alpha value to GdkColor like the r/g/b ones already are (?) Sounds like a long process of deprecation by policy, but i agree that GdkGCs don't make much sense anymore if at all. Milosz On 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote: Shouldn't GdkGC be deprecated now that we have cairo contexts? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
Yes, that's what i meant by deprecation by policy (i.e. you'd say it's deprecated, but don't remove the code or anything, you just discourage it's use; although that might be not the proper word for it, i'm sorry in that case as i'm not a native english speaker) The problem is just there are a dozens of style engines and they use the GdkGCs directly, so basically all style engine writers would be encouraged to use cairo for drawing and not access the GdkGCs. On 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote: I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors.So, I guess that should be ported too.In general, deprecation doesn't mean that you may not use it. Deprecation is n't breaking. I am currently unaware of whether the style engines access them directly but i'd rather think they do, so this would require the style engines to 1) only use the GdkColors of the style and (while we're at) 2) add an alpha value to GdkColor like the r/g/b ones already are (?) Sounds like a long process of deprecation by policy, but i agree that GdkGCs don't make much sense anymore if at all. Milosz On 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote: Shouldn't GdkGC be deprecated now that we have cairo contexts? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list Murray Cumming[EMAIL PROTECTED]www.murrayc.comwww.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
One first step could be to back all gdk_draw_*() functions with actual cairo drawing (disabling antialiasing so compatibility is kept) and reading only the color values off the GCs, and then officially deprecate the GdkGCs. (Not entirely sure if that makes sense, RFC)That way at least the GdkGCs would lose their actual meaning within GDK and thus become deprecated by implication. The biggest problem in removing the GdkGCs are really the style engines. On 12/1/05, milosz derezynski [EMAIL PROTECTED] wrote: And in addition all current style engines would need to be ported, since once the GdkGCs are declared as deprecated, it would as a consequence deprecate the styles engine's code as well. On 12/1/05, milosz derezynski [EMAIL PROTECTED] wrote: Yes, that's what i meant by deprecation by policy (i.e. you'd say it's deprecated, but don't remove the code or anything, you just discourage it's use; although that might be not the proper word for it, i'm sorry in that case as i'm not a native english speaker) The problem is just there are a dozens of style engines and they use the GdkGCs directly, so basically all style engine writers would be encouraged to use cairo for drawing and not access the GdkGCs. On 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote: I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors.So, I guess that should be ported too.In general, deprecation doesn't mean that you may not use it. Deprecation is n't breaking. I am currently unaware of whether the style engines access them directly but i'd rather think they do, so this would require the style engines to 1) only use the GdkColors of the style and (while we're at) 2) add an alpha value to GdkColor like the r/g/b ones already are (?) Sounds like a long process of deprecation by policy, but i agree that GdkGCs don't make much sense anymore if at all. Milosz On 12/1/05, Murray Cumming [EMAIL PROTECTED] wrote: Shouldn't GdkGC be deprecated now that we have cairo contexts? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list Murray Cumming[EMAIL PROTECTED] www.murrayc.comwww.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecate GdkGC?
On Thu, 2005-12-01 at 22:50 +0100, milosz derezynski wrote: I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors. ... and apps still do this: gdk_gc_set_clip_rectangle (widget-style-black_gc, my_rect); gdk_draw_pixbuf (widget-window, widget-style-black_gc, my_pixbuf, ...); gdk_gc_set_clip_rectangle (widget-style_black_gc, NULL); I mean, that would still work. But if we schedule GCs for deprecation, we need really really good docs on how to migrate everything to Cairo. Actually, we have needed those since Cairo became the preferred drawing API instead of gdk_draw_*()... Any takers? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
