Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Thu, 19 Feb 2004 16:00:08 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: The decision if the plug-in needs the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. Basically, yes. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list. If you would have proposed it as a requirement at that stage I would have rejected it, because I simply think that it is infeasible as it stands. There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. A few points: * How do you detect that parameters have been changed? Users will expect that the preview gets updated when they change some parameters. Many plug-ins do not need to detect this at the moment because the values only become relevant when the user presses the OK button. When rewriting such a plug-in you will have to add modification detection code, and you will also have to modify the code that collects the current values of the parameters and runs the underlying algorithm with these parameters. Some plug-ins completely mix their business logic with their GUI and in these cases it might require quite a bit of work to fix this. * Current plug-ins assume that they can write the results back to the input drawable. So you will either need to coerce to write back their results somewhere else or you will have to mess around with the original drawable (probably some hidden global preview-mode switch). * Current plug-ins are not very flexible in the area that they render. Some always generate the entire drawable, and others generate the area from gimp_drawable_mask_bounds. For the latter category you could of course think of a hack that changes the output of gimp_drawable_mask_bounds based on some hidden global preview-mode switch, but then you will also have to consider the consequence of this decision for all other places where this function may be used, not to mention the fact that the whole idea of global mode switches is inherently ugly. So I don't think that should try to find some solution without rewriting, but to find some framework that could easily fit a large set of the current plug-ins. The change should be limited to the plug-in dialog and a few hooks here and there. Unless there have been some major changes to the GIMP plug-ins since I last looked at them, I believe that this idea is not very realistic. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem. It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward. But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the core operations on it. So I am not really certain if it would be worth the effort. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins?
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe [EMAIL PROTECTED] writes: However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list. I am pretty sure this point was mentioned. IIRC it has already been discussed on GimpCon 2000 and I think it's the basic and most important design requirement. There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. Without going into much details of your answer, it is clear that you completely missed my point. Of course there are some changes needed to the plug-in code. How large the changes are depends on the quality of the code, mainly in the user interface parts of it. When I said that only few changes should be needed when adding a preview, I was assuming an otherwise well-designed and well-written plug-in. The point I was trying to make is that the actual image manipulation algorithm should not have to be touched. For the code that operates on the actual pixels, there must not be a difference between rendering the result or rendering the preview. This means that this routine can always work on a GimpDrawable and doesn't need to care if this struct wraps a real drawable or just some preview data. The preview doesn't even need to be tile-based (I think you said it would have to be). Plug-ins usually don't see any tiles, they work on pixel regions and that's exactly the API that they should be using when rendering a preview. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins? Yes. I think this is a safe assumption for the general case. Not too many plug-ins call other plug-ins. In the GIMP source tree there is not a single one that would need a preview and calls other plug-ins. Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows. I am afraid that with this definition there are very few good plug-ins. That is correct, but if we provide a preview API that encourages to write good plug-ins, this number will increase. If our preview API is modeled after the bad sort of plug-ins, we will never get a reasonable codebase in the plug-ins directory. Of course my proposal also allows for a row-based algorithm since GimpPixelRgn provides that as well. Now obviously you have a problem with having to allocate temporary drawables in the GIMP core just for the sake of previewing. But what is the problem? Is it just a performance issue? As far as I have seen, it is not a serious issue, I have a pretty slow computer and the performance of the preview is quite acceptable. In most cases the drawables are pretty small, much smaller than the real images. In general I am pretty skeptical about design decisions that sacrifice simplicity for performance's sake, in the long term that is generally a bad strategy (yes there are some cases where it is a correct decision but you should always analyze them pretty carefully). Performance is not the primary concern here. The problem is that if we encourages plug-ins to allocate temporary drawables in the core, we would have to add a framework that makes sure that these drawables aren't leaked. One of the main reasons to keep plug-ins as separate processes is to ensure that a badly written plug-in doesn't make the GIMP core leak memory. I am pretty sure that temporary drawables created by plug-ins will eat up our tile-cache quite fast. In the long run we will have to improve how resources allocated by plug-ins are handled in the core. The core should be able to undo all operations in case a plug-in crashes and it should free all floating resources when a plug-in finishes it's job. If such a framework is in place, we can easily change the preview code to optionally allow a preview in the image window. The plug-in will then simply work on a core drawable and this can happen completely transparently. Most existing plug-ins will write their output only to their input drawable. But for the preview we don't want to modify the original drawable, but the plug-in must somehow be coerced to write its output to something that the preview could read. If you really don't want to change the plug-ins algorithm at all the only solution is to somehow intercept the modifications to the original drawable and route them to the
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 16:19:06 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables. Well, if the plug-in needs to allocate temporary drawables in order to conveniently display a preview, than this is a problem of the preview. The decision if the plug-in needs the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable. One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem. It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward. But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the core operations on it. So I am not really certain if it would be worth the effort. Furthermore, this functionality would only be needed for those plug-in algorithms where it is difficult to compute an entire row of pixels, and actually I cannot remember that I have ever seen one. So if you have some good examples, perhaps the problem could also be solved by changing the interface of the preview, e.g. adding support for drawing tiles on the preview. Anyhow, it does not have any real impact on the preview. At most, I would have to change a few lines in two of the helper functions. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: Ernst Lippe [EMAIL PROTECTED] writes: The decision if the plug-in needs the temporary drawable is made by its designer and it is certainly not forced by the preview. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. It is certainly a step in the right direction, though, and I think that it is something that we should try to use (and improve) during the 2.1 cycle. It is more than a simple widget that you draw on too - you get feedback from the widget about which pixel region is currently in the viewport, and you can quite easily generate a drawable from that which you pass to your filter function. Given that there are now 2 developers interested in working on this (Ernst and dindinx) I think there is a good chance that working together on it (in GIMP CVS, so that we get some feedback from the plug-in authors who use it too) we will have a nice to use preview widget by 2.2 Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe wrote: Sven Neumann [EMAIL PROTECTED] wrote: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the update-preview signal? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe [EMAIL PROTECTED] writes: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As far as I remember the major problematic point was the fact that the preview creates temporary drawables in the core instead of handling the preview completely on the plug-in side. Has this been addressed as well? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 10:18:58 +0100 Dave Neary [EMAIL PROTECTED] wrote: Hi, Ernst Lippe wrote: Sven Neumann [EMAIL PROTECTED] wrote: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the update-preview signal? Something like this was present in the old preview, I deliberately removed it because it was an unnecessary overhead for some plug-ins. The first question that you face when you want to add this, should the drawable be scaled or not? There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview. Also, I have added a utility function to the preview (gimp_preview_get_temp_drawable) for doing this, so it is very easy for the programmer to do this in the signal handler. If you want to send a scaled drawable, for several algorithms this is simply useless overhead because they can't use it. There are many plug-in algorithms that are not scale-invariant in the sense that the scaled version of their output is different from the output when they use a scaled input. Also several algorithms have an output area that is different from their input area. Yet another class of algorithms are those that simply generate a new image that is independent from the input image. For all these classes of algorithms a scaled drawable is simply useless overhead. So when you really want to let the preview generate a scaled drawable, it should definitely be optional. In that case there would be yet another parameter for the preview, and the internal code would have to be more complicated (at the moment it only draws directly to the underlying GtkImage and that should be modified to write to the drawable as well). Also, I am not convinced that there would be a real performance advantage, for most plug-ins that I have seen, the plug-in algorithm itself will be the main bottle-neck. For those algorithms that really want a scaled drawable there is another utitility function (gimp_preview_get_scaled_drawable). Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 13:51:40 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As far as I remember the major problematic point was the fact that the preview creates temporary drawables in the core instead of handling the preview completely on the plug-in side. Has this been addressed as well? No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe [EMAIL PROTECTED] writes: No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables. Well, if the plug-in needs to allocate temporary drawables in order to conveniently display a preview, than this is a problem of the preview. One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem. It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, 06 Feb 2004 16:51:28 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, David Odin [EMAIL PROTECTED] writes: Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig? GFig is supposed to be completely replaced by the vectors tool sooner or later so that's probably not a good example. I wish plugins like gfig would operate on the image/view, not in separate window like now. We are mainly seeking for a short-term solution here that allows to add a preview to existing plug-ins w/o too many changes. What you are asking for is pluggable tools. This was attempted in the 1.3 series but we backed this change out because it exposed too much internals that are not yet in the state where we want anything but the core to work with it. MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough. A GEGL-based GIMP is supposed to allow exactly that but we will have to do some rather major changes before this becomes real. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, David Odin [EMAIL PROTECTED] writes: It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal. Integrating with GIMP's internal? There's no need for such a widget in the GIMP core (and we have GimpPreview in the core already). What we are looking for is a preview widget that is especially modeled for the need of GIMP plug-ins. How would this integrate with internals? I guess I somehow misunderstood you here. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:02:37PM +0100, Sven Neumann wrote: Hi, David Odin [EMAIL PROTECTED] writes: It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal. Integrating with GIMP's internal? There's no need for such a widget in the GIMP core (and we have GimpPreview in the core already). What we are looking for is a preview widget that is especially modeled for the need of GIMP plug-ins. How would this integrate with internals? I guess I somehow misunderstood you here. Sorry. I haven't been clear enough here. GimpPreview as I see it should be able so show exactly the same thing as a Drawable, but with a different scale. For instance, it should be able to show the composited image, with a background layer or whatever. This sort of thing could involve more than just gdkrgb functions, that's why I said this _could_ use more gimp's way of rendering than gtk's. Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. Regards, DindinX -- [EMAIL PROTECTED] Laugh alone and the world thinks you're an idiot. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: David Odin [EMAIL PROTECTED] writes: What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. This would be cool. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, David Odin [EMAIL PROTECTED] writes: Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it: http://refocus.sourceforge.net/preview/gimppreview.html Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:51:28PM +0100, Sven Neumann wrote: Hi, David Odin [EMAIL PROTECTED] writes: Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it: http://refocus.sourceforge.net/preview/gimppreview.html I wasn't aware of this. I'll have a look. Thanks. DindinX -- [EMAIL PROTECTED] Despite the cost of living, have you noticed how it remains so popular? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Dave Neary [EMAIL PROTECTED] writes: I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see. I'm a bit confused now since we discussed all details of the widget several months ago. It might be worth to dig out that discussion again because it had a very good list of requirements. The main point is that of course since you want to preview a plug-in's result, the plug-in shouldn't have to run the complete drawable thru whatever pixel manipulation routines it applies. There wouldn't be a need for a preview widget then, you could simply apply the effect. The preview widget needs to be smart enough to cause only the visible area to be processed (from an idle handler so that the GUI remains responsive). For a zoomed preview it needs to pass scaled data to the plug-in's pixel manipulation routines which may then have to adapt to the scale ratio that is applied. Ideally the same pixel manipulation routines of the plug-in should be used for rendering the actual result on the drawable as for rendering the preview. Since we don't want to introduce major changes to the plug-in, the preview API should probably provide a fake drawable that the plug-in can work on. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
