On 4/24/06, Alexandre Prokoudine <[EMAIL PROTECTED]> wrote: > On 4/24/06, BERGER Cyrille wrote: > > > 1. How exactly many developers like the idea of having uniform API for > > > plug-ins? > > me :) > > That's a good start :)
The problem with any such approach is that it caters to the lowest common denominator. This makes such a filter/plug-in/effect framework only suitable for the common subset and is likely to suffer either in quality and performance compared to native plug-ins. GEGL will demand reference implemententations of >=32bit floating point accuracy, mechanisms for minimizing temporary buffers to reduce computational overhead when rendering subregions, and hopefully even scale invariant/tolerant parameters. Other efforts to achieve cross application image/video processing plug-ins already exist, various applications have different needs. Dataflow(/graph) based designs like GEGL have the advantage that supporting new types of plug-ins are relativly easy. GEGL will aim to support legacy 8bit only GIMP plug-ins through an adapter. Such adapters could also be made for freeframe[1], Frei0r[2], livido[3] and foobar[4]. 1: http://freeframe.sourceforge.net/ 2: http://www.piksel.org/Frei0r 3: http://livido.dyne.org/ 4: http://pippin.gimp.org/gggl/ops.html 5: insert missing standard effect/filter plug-in architecture here. > > But, anyway, it's the heart of the problem, plugins often require a > > configuration widget, and GTK apps will want a GTK widget and Qt apps > > a Qt widget (and don't forget about wx and fltk ;) ), and we cannot > > ask all plugins devs to provide a widget for all toolkit. (one > > solution would be to provide a xml description of widgets (like Qt's > > ui files) and let the host application transform it to its favorite > > toolkit widget). > > I'm not sure what you mean with a configuration widget. Do you mean > custom widgets? For plug-ins to be easily shareable in such a scenario it is important that parameters and their ranges are discoverable through introspection. This will be done in GEGL thorugh the use of gparamspecs. This allows some guaranteed support. Bauxite[6] for instance the default way is to use simple entries/slider for strings/doubles. But also allow the host application to recognize the plug-in and provide a specialized vector widget that controls those same parameters. 6: http://pippin.gimp.org/bauxite/ > > > 4. Is it possible at all to create a uniform API for plug-ins that > > > could work e.g. in both Krita and GIMP (and with GIMP I mean upcoming > > > GEGL-based GIMP) with regard to color management, bit depth (8/16/32 > > > floating point per channel), color spaces etc? > > > > And I think you forgot at least one question: > > 5] what plugins are to be common ? tools ? filters/effects ? > > colorspaces ? file import/export ? "batch" processing (like > > kipi-plugins) ? My answer to question #4 is, yes and no, and it might not even be neccesary if one of the existing ones could already be adapted to some of the needs. /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
