* Calvin Williamson <calvinw@xxxxxxxxxxxxxx> [040923 18:02]: > Anyway I think we commit to stick to double or float > as the default, and decide which other types to support as well, It makes sense to enforce this for most filters, but some source operations (mpeg4, png, v4l, svg (at least my cairo based thing)) it doesn't make sense, the plug-in system should allow for developers to just code for the pixelrepresentations they need, ignore the rest, and be able to expect things to just work. In gggl I do pixel representation negotiation in a seperate pass before processing starts (this could be added as an additional pass in GEGL as well I guess), this pass does negotiation on every connection in the graph trying to find the best suited common format between the operations, if no suitable pixel representation is found a proxy operation is inserted proxy is my pixel representation "babelfish" http://pippin.gimp.org/gggl/snapshot/ops/filters/pixfmt_conversions.h.html http://pippin.gimp.org/gggl/snapshot/ops/filters/precalc_order.txt.html http://pippin.gimp.org/gggl/snapshot/ops/filters/proxy.c.html > and try to make it as easy as possible to add new types, but without > burdening it all with a code-generating tool right now. Code generation is generally a good idea,. but a single standard is not a good idea IMO. For instance the porter-duff operators have a very similar structure, not using code generation / #include tricks or something similar the amount of code gets quite large, fast. http://pippin.gimp.org/gggl/snapshot/ops/composers/porter_duff/generate.rb.html is the ruby based code generator I use in gggl to generate them all (I should probably look into extending the porter duff code to be both 8bit, 16bit and float since it is a case where a little work on the code generator will provide a lot of functionality.) Defining a scripting language as a prerequisite for generating the GEGL source (perhaps not true for tarballs?). /pippin
