On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote: > On 11/8/12, Jon Nordby <jononor@xxxxxxxxx> wrote: > > Has your work on replacing the deprecated functions found its way into > > git master? > > No. With Mitch's help I did made a patch file (which might be out of > date by now, as Gimp keeps changing): > http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html#patch Indeed :) I cleaned up that patch to match GIMP's coding style, fixed some little things, and attached it to: https://bugzilla.gnome.org/show_bug.cgi?id=662739 Let's continue the patching and patch discussion in this bug. I also added a comment on the patch there. > > * Change the lcms-based conversion (modules/display-filter-lcms.c) > > from being a generic display filter to be something that takes a > > GeglBuffer in and blits into a cairo_surface_t. > > * Change the display filter interface to accept a GeglBuffer instead > > of a cairo_surface_t. As gimp_color_display_convert_surface is public > > API, it should probably become a stub and be marked as deprecated. New > > interface could for instance be called > > "gimp_color_display_convert_buffer" > > * Adapt all the display filter operations (modules/display-filter-*.c) > > to the new interface and to working on 32bit floating point. If any of > > the operations are no longer useful, now would be the time to drop > > them. > > * In the use of the display filter stack (in > > gimp_display_shell_render), first let the filter stack operate on the > > GeglBuffer from the projection (or possibly a copy), and then pass it > > to the lcms-based color conversion, and then pass that to cairo. > > -- > > Jon Nordby - www.jonnor.com > > > > I'm looking forward to taking another look at the monitor display code > path. Your suggestions sound very helpful. It does, but it's clearly step 2 (or step n). IMO we should first get the lcms plug-in right so the data GIMP is dealing with is correct in the first place. > When I started looking at Gimp color management I had no idea how very > complicated Gimp code is. The light began to dawn as I tracked down > the functions that are involved in sending image data to the monitor. > Then I traced the function calls from the time Gimp is started until > main.c hands control over to Glib (g_main_loop_run). Glib? > > I have a sense of how Gimp and Gegl, and Gimp and Babl, interact. > Would some kind soul be willing to provide a quick overview of the > relationship between Gimp and Glib? And between Gimp and Cairo? I > realize that Cairo sends the image data to the screen, but what is the > advantage of using Cairo? GLib and GTK+ were originally developed inside GIMP and then split out to be independent packages ages ago. GTK+ is the user interface toolkit, GLib is a whole framework of cross-platform utility functions, featuring stuff like lists, hash tables, the main loop and tons more. Cairo is how GTK+ and GIMP render everything for GUI display, its advantage is that before we used wrappers around stone age X11 API which is complete and utter legacy. Cairo is vector based and proper. For more detailled explanations, google and #gimp IRC are your friends, I haven't seen you on IRC in a long time anyway :) Regards, --mitch _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
