Re: [Gimp-developer] PDB requirements
David Neary wrote: Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort? It's really not all that useful if we don't have paint event recording. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Hi, Kelly Martin wrote: > Manish Singh wrote: > >I was asking more in terms of an API should look like. Interactive > >paint is more involved than say, a bucket fill, which is easily translated > >into to "call PDB bucket fill function on button release". > > Especially when you consider the airbrush, which has time sensitivity as > well as motion sensitivity. > This is nonsimple to begin with, and making it efficient is even more > complex. You don't want substantial redraw delays while painting. I am not > sanguine on getting this implemented in the desired three month window. Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
* Kelly Martin <[EMAIL PROTECTED]> [040326 21:12]: > Manish Singh wrote: > > >We could simply bypass the pdb for painting, and just emit "record this" > >on button release. But maybe it'd be better to have the pdb more involved, > >I dunno. > > You'd at least have to serialize all the events for the paintbrush and > airbrush if you want the macro to be brush- and color- independent (that > is, you are interested in capturing the motions used, rather than the > result). You could save the serialization in a buffer and then spew it > forth at the end, but I don't see any way around collecting the actual > paint events. Ideally you want to implement this code in an resolution independent manner as well. Thus all motion events should be interpolated in some manner,. when zoomed out drawing freehand shapes are guaranteed to create coordinate quantification in the shape, unless the coordinates are interpolated, and ideally translated to a curve. If a procedual GEGL operation is lying below,. you could just pass the controlpoints of the curve to the function,. at some level the bezier/spline curve could perhaps also be smoothed within a threshold, when using tools freehand, before passing it to the drawing op itself,. doing it in this manner allows parametric data to be cached for a more advanced and memory efficient undo op stack as well. > This was a requirement when I was asked to this by my former employer back > in 2000, and also a requirement for the guy who was trying to contract > Wilberworks to do it back in 1998. I think a macro recorder that doesn't > capture motion events will be of limited utility to users. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh wrote: We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno. You'd at least have to serialize all the events for the paintbrush and airbrush if you want the macro to be brush- and color- independent (that is, you are interested in capturing the motions used, rather than the result). You could save the serialization in a buffer and then spew it forth at the end, but I don't see any way around collecting the actual paint events. This was a requirement when I was asked to this by my former employer back in 2000, and also a requirement for the guy who was trying to contract Wilberworks to do it back in 1998. I think a macro recorder that doesn't capture motion events will be of limited utility to users. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
On Fri, Mar 26, 2004 at 06:53:28PM +0100, Michael Natterer wrote: > >> Manish Singh <[EMAIL PROTECTED]> writes: > > Well, something has to generate those coords, and something has to update > > the UI before painting is finished. > > > > I was asking more in terms of an API should look like. Interactive > > paint is more involved than say, a bucket fill, which is easily translated > > into to "call PDB bucket fill function on button release". > > IMHO this is not a big issue, since even today PDB painting uses almost > the same functions as interactive painting does. The only difference > is that PDB painting flushes the stuff at the end while interactive > painting flushes while painting. > > So everything that would have to be changed is replacing the call > to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() > and flush the display in between. Not a big deal i'd say. > > (What I want to say is that painting has been abstracted well > enough to enable stroke recording without changing too much). > > But then you are right, maybe we need a new API because it's > perhaps cleaner to just draw the stuff as we do now and to > create the recorded entry on button_release() Right, it wouldn't be hard to adapt the code to do this. But we should nail down a sane API... We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh wrote: I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release". Especially when you consider the airbrush, which has time sensitivity as well as motion sensitivity. The general paint UI (used for paint/pencil/erase, clone, smudge/dodge/burn, and airbrush, IIRC) has to generate an drawing event for each drag. The airbrush also has to generate one for each timer tick while the mouse is down, whether or not a drag occurred. The other tools generate only one drawing event, at mouse release. The lasso can probably only generate one drawing event, at mouse release, but its event structure is considerably more complex than the rest. I'm not sure about the various vector-related tools. This is nonsimple to begin with, and making it efficient is even more complex. You don't want substantial redraw delays while painting. I am not sanguine on getting this implemented in the desired three month window. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh <[EMAIL PROTECTED]> writes: > On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote: >> Manish Singh <[EMAIL PROTECTED]> writes: >> >> > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: >> >> On Sun, 21 Mar 2004, Manish Singh wrote: >> >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: >> >> > > What requirements would the new PDB have? >> >> > >> >> > There's a number of issues to be addressed, like GEGL node support, >> >> > efficiency, UI generation, distributed processing, and macro recording >> >> > support. >> >> >> >> Macro recording is already trivial with libpdb: you just connect to the >> >> appropriate signal of the Pdb object. >> > >> > Have you given any thought on how to macroize interactive paint >> > functions? >> >> By simply passing an array of GimpCoords to the yet-to-be-generated >> core PDB wrappers, just as all core functions will have to be invoked >> via these wrappers to make marco recording possible. > > Well, something has to generate those coords, and something has to update > the UI before painting is finished. > > I was asking more in terms of an API should look like. Interactive > paint is more involved than say, a bucket fill, which is easily translated > into to "call PDB bucket fill function on button release". IMHO this is not a big issue, since even today PDB painting uses almost the same functions as interactive painting does. The only difference is that PDB painting flushes the stuff at the end while interactive painting flushes while painting. So everything that would have to be changed is replacing the call to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() and flush the display in between. Not a big deal i'd say. (What I want to say is that painting has been abstracted well enough to enable stroke recording without changing too much). But then you are right, maybe we need a new API because it's perhaps cleaner to just draw the stuff as we do now and to create the recorded entry on button_release() ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote: > Manish Singh <[EMAIL PROTECTED]> writes: > > > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: > >> On Sun, 21 Mar 2004, Manish Singh wrote: > >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: > >> > > What requirements would the new PDB have? > >> > > >> > There's a number of issues to be addressed, like GEGL node support, > >> > efficiency, UI generation, distributed processing, and macro recording > >> > support. > >> > >> Macro recording is already trivial with libpdb: you just connect to the > >> appropriate signal of the Pdb object. > > > > Have you given any thought on how to macroize interactive paint > > functions? > > By simply passing an array of GimpCoords to the yet-to-be-generated > core PDB wrappers, just as all core functions will have to be invoked > via these wrappers to make marco recording possible. Well, something has to generate those coords, and something has to update the UI before painting is finished. I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release". -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
Manish Singh <[EMAIL PROTECTED]> writes: > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: >> On Sun, 21 Mar 2004, Manish Singh wrote: >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: >> > > What requirements would the new PDB have? >> > >> > There's a number of issues to be addressed, like GEGL node support, >> > efficiency, UI generation, distributed processing, and macro recording >> > support. >> >> Macro recording is already trivial with libpdb: you just connect to the >> appropriate signal of the Pdb object. > > Have you given any thought on how to macroize interactive paint > functions? By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: > On Sun, 21 Mar 2004, Manish Singh wrote: > > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: > > > What requirements would the new PDB have? > > > > There's a number of issues to be addressed, like GEGL node support, > > efficiency, UI generation, distributed processing, and macro recording > > support. > > Macro recording is already trivial with libpdb: you just connect to the > appropriate signal of the Pdb object. Have you given any thought on how to macroize interactive paint functions? > Distributed processing will soon be supported by libpdb using the > WireSocket backend; this will be done by early May. Implementing > WireSocket is one of the group projects chosen by some of the students in > a class I am taking, so it will be done if they want a good grade. :) Heh. Maybe local UNIX sockets are faster than pipes. Would be good to benchmark. > UI generation is mostly out of the scope of libpdb. I would have to know > more what is specifically meant by "UI generation" before I could comment > on it. Generate a UI from a PDB entry. Like a generalized -fu that the scripting languages currently have. This makes an easy way of generating property panes for nodes in a graph say, made out of PDB nodes. > Efficiency has yet to be addressed by libpdb, although some easy > optimizations have been put in place. Serious optimization should > probably wait until the feature requirements are more in place and > reasonable profiling can be done. Yeah. For macro recording things should to go through the PDB in the app itself, so the within process boundary case things should be lightweight and fast. > GEGL node support opens a big can of worms, and there probably is no best > solution. The first big decision to make is whether plug-ins should be > written as GEGL nodes objects directly, or whether there should be a shim > GEGL node that translates the operations into procedural calls not unlike > those in the traditional GIMP api. > > If we do use a translating shim, Libpdb seems like a good fit for this as > well. Yes, that's undetermined. > It seems like a real shame to lose GIMP's ability to run plug-ins out of > process, so my vote is we rule out dynamically loading gegl nodes using > GPlugIn as the only method, although we may want to be able to do it as > an additional extra-fast method. > > CORBA seems like a flexible choice here if we decide to make plug-ins > implemented directly as gegl nodes. Although my guess is it would add > somewhat more overhead than a hand-rolled gimp-specific method, it has the > advantage of being more flexible than anything we could do, and also it > would be something maintained by an outside group instead of another > burden for us. I dunno. CORBA is pretty heavyweight, there isn't an ORB out there that does things efficiently. > If we do decide to have plug-ins be native GeglNodes, I recommend that we > still have a PDB for scripting purposes. A node has inputs and outputs, and so do PDB functions, so there isn't much difference there. I've thought about doing a proxy GObject framework, which would allow IPC of arbitrary objects, but I haven't fleshed it out in my mind yet. One thing I've thought about would be to use the object and type system features, like every PDB function is an object, with properties for parameters. A paramspec has everything we need: type, name, descriptions, defaults, possible bounds. Maybe something like a PDB function is an object, you set properties on it, then run the execute method. Also have a print method for a textual representation. Then just instantiate and string together these objects, and run through then. Sort of like CellRenderers in GtkTreeView. This might be a complete and total abuse of the object system tho, and not scale at all. I might do a quicky implementation and see. Using paramspecs somehow is tempting though. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Sun, 21 Mar 2004, Manish Singh wrote: > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: > > How far along is the planning? I have heard of Rock's libpdb, > > which I believe he wants to finish for 2.2, but I hadn't heard > > any concrete plans for the often-mentioned forthcoming PDB > > re-write. > > There hasn't been any real planning, other than planning to do some planning > after 2.0 is out. All I was saying is that we haven't forgot about it. 2.0 is out now. :) > > What requirements would the new PDB have? > > There's a number of issues to be addressed, like GEGL node support, > efficiency, UI generation, distributed processing, and macro recording > support. Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object. Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :) UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by "UI generation" before I could comment on it. Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done. GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api. If we do use a translating shim, Libpdb seems like a good fit for this as well. It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method. CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us. If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
