Re: [Gimp-developer] plug-in preview widget (another try)
On Fri, 2004-05-21 at 21:57 +0200, Sven Neumann wrote: [Thanks for CCing me on this, Sven; I don't follow gimp-developer as closely as I would like these days] There seem to be a couple of options. Let me try to summarize the ones that I see: - Use GtkPreview. GtkPreview is declared deprecated by the GTK+ team and we will want to get rid of it at some point. On the other hand there isn't really a good reason not to use it. The API does it's job w/o and I never understood why it as deprecated in the first place. The GIMP should get rid of GtkPreview as soon as possible. It is a deprecated API, and it is a horrible API regardless of its deprecation status. From the viewpoint of the GIMP and likely elsewhere, this is why it is horrible: - It only supports a draw_row() API. This is very cumbersome for filters, which must generate a temporary buffer and then copy it row by row to the GtkPreview. - It doesn't handle opacity information. Plug-ins must composite their images against a checkerboard or some other sort of background by hand. - It doesn't handle scrolling, zooming, etc., which are very useful for previews in an image editor. - Use a GdkPixbuf as the pixel buffer and use a GtkImage to display it. The disadvantage is that the GdkPixbuf and GtkImage API are not too well suited for our needs. GdkPixbuf doesn't handle greyscale buffers and GtkImage can only display the full pixbuf. If we wanted to show only a region of the buffer we could work around this using gdk_pixbuf_new_subpixbuf() but IMHO this is becoming too hackish to consider it. GtkImage is just a way to easily slap an image into a window, for example, to put an icon in a dialog box. It's not designed to display non-static images or those that need scrolling/zooming/etc. GdkPixbuf is not meant to be *THE* one representation for images that all programs should use; it is just the representation that GTK+ understands. It also happens to be a convenient representation for simple programs as well; this is obviously not the case for the GIMP. I'm not sure if the GIMP can use some of the interesting functions in GdkPixbuf such as the composite-on-checkerboard stuff --- you already have code in the GIMP to composite against checkerboards for image windows. But if you find any use in that code in GTK+, by all means use it. - Come up with a full-featured preview widget. We could use the widget that Ernst Lippe wrote but since there hasn't been any effort so far to discuss it's API again and to get it into CVS I am not sure if it makes sense to wait for this to happen. This is the right way to go. I'd say the list of requirements for a preview widget for the GIMP are at least the following: 1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview: - scale the original image by 1/N - blur with a radius of 1/N pixels - draw that as the zoomed-out preview That is, it won't show exactly the same result as if you did - blur the original image with a radius of N pixels - scale the result by 1/N - draw that as the zoomed out preview but it will be pretty useful anyway. 2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, render the area at (xofs, yofs, width, height). If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, render the area at (xofs - 10, yofs, 10, height). That is, rendering of the preview should be incremental based on scrolling. 3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...) This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins. 4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor. 5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows. I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth. I don't think an API for super-slow filters is even worth
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Federico Mena Quintero [EMAIL PROTECTED] writes: - Come up with a full-featured preview widget. We could use the widget that Ernst Lippe wrote but since there hasn't been any effort so far to discuss it's API again and to get it into CVS I am not sure if it makes sense to wait for this to happen. This is the right way to go. Did you look at the implementation details and the API? I don't think we should use this preview widget because it has a cumbersome API and some design flaws that we can hardly work around later. It certainly makes sense to study it and to use what's good about it but it should IMHO not be put into the gimp source tree without a major redesign. I'd say the list of requirements for a preview widget for the GIMP are at least the following: 1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview: - scale the original image by 1/N - blur with a radius of 1/N pixels - draw that as the zoomed-out preview That is, it won't show exactly the same result as if you did - blur the original image with a radius of N pixels - scale the result by 1/N - draw that as the zoomed out preview but it will be pretty useful anyway. 2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, render the area at (xofs, yofs, width, height). If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, render the area at (xofs - 10, yofs, 10, height). That is, rendering of the preview should be incremental based on scrolling. 3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...) This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins. 4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor. 5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows. I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth. IMO it makes a lot more sense to first design a preview widget that provides enough functionality to replace GtkPreview now. This includes point (4) and (5) but not (1), (2) and (3). Later a more sophisticated framework can be added on top of this. The reason to do it this way is that we already tried it the other way around and it didn't work out. If we go for the simple preview widget as I proposed, there's a good chance we can get all the API issues sorted out during the next week or two. This means that we can get a sane API into gimp-2.2. If we try to create the super-preview-widget again we will probably not get aything done before the feature freeze. Federico, the real reason why I put you into Cc: was to get a word about you on the Unsharp Mask patch that you said you wanted to work on. If you don't expect to find time for it soon, then please say so. People are waiting to have their patches committed and I'd really like get the outstanding preview patches in as soon as possible. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Monday 24 May 2004 19:11, Federico Mena Quintero wrote: This is the right way to go. I'd say the list of requirements for a preview widget for the GIMP are at least the following: 1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview: - scale the original image by 1/N - blur with a radius of 1/N pixels - draw that as the zoomed-out preview That is, it won't show exactly the same result as if you did - blur the original image with a radius of N pixels - scale the result by 1/N - draw that as the zoomed out preview but it will be pretty useful anyway. 2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, render the area at (xofs, yofs, width, height). If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, render the area at (xofs - 10, yofs, 10, height). That is, rendering of the preview should be incremental based on scrolling. 3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...) This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins. 4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor. 5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows. I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth. As far as I can see my preview widget can satisfy all of your requirements. I don't think an API for super-slow filters is even worth considering. People should just learn to write faster code :) That's not always possible. There are several classes of interesting algorithms, e.g. most image enhancement techniques, that are inherently slow. Also the fact is, that most current plug-ins are indeed not very efficient. But especially with slow algorithms you desperately need a preview. And even with a fast algorithm there will be cases when the user is probably faster, e.g. while scrolling or zooming a large preview image. So I certainly believe that slow algorithms are an important use case for the design of a preview. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Saturday 22 May 2004 14:54, Sven Neumann wrote: geert jordaens [EMAIL PROTECTED] writes: Signals : 1. preview_draw : draw preview area from current preview buffer. 2. preview_update: Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed) I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it. But the position of the previewed area and the current magnification are inherently properties of the preview itself. It seems pretty logical to make scroll and zoom buttons part of the preview widget and in that case it is the preview widget that will detect if the position or scale has been changed. So the most logical design is to let the preview call the plug-in algorithm and not the other way round. I can see nothing wrong with using signals in this case, because they are more flexible than the other standard solution of having call-back functions. Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews? Such a framework can be added later as I outlined in the proposal I just sent to the list. The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it. Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer. How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the right size for this buffer), it will cause a performance hit on many normal preview operations. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Saturday 22 May 2004 22:40, Nathan Carl Summers wrote: On 22 May 2004, Sven Neumann wrote: So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think? There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. There are good arguments for incremental update, and good arguments for a progressbar. For very slow plug-ins incremental updates are better, because the user can sooner detect and remedy any problems with the parameter setting or the correct scroll position sooner. It is especially useful during scrolling because it is frequently possible to determine from a small part of the new image if you are at the desired position or not. When the preview image only shows a progress-bar you loose this type of immediate feedback. (In my current version of the preview incremental updating does not work, even though I call gtk_widget_queue_draw on it. Like Sven indicated, I would probably need to call back to the GLib main loop) But I think the real issue here is that slow previews should be computed in small chunks in an idle handler so as to not impede interactivity. Another very important issue is how these computations can be halted when the image that is being computed has become obsolete. In my experience this happens very frequently. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Ernst Lippe [EMAIL PROTECTED] writes: Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews? No, I want to use the GtkScrolledWindow API for the scrolling and the standard GtkWidget API for resizing. I want to completely leave scaling out of this first basic widget. It will allow us to get rid of GtkPreview and that's the main problem we need to solve now. Of course it's a good idea to think beyond that and I agree that we will need a more complex preview widget than what I proposed to start with. However this is all not finished and I am open for other ideas. Actually I am not too happy with the proposed API, especially the fact that the buffer is outside the preview and how scrolling would have to be handled. So I am perfectly willing to reconsider it. What is the point about plug-ins that have multiple previews? I fail to see the problem; perhaps you can explain it to me. I am currently trying to come up with a proposal for GimpDrawablePreview, an extension to the GimpPreview interface that should allow plug-ins to reuse their rendering function for the preview. How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the right size for this buffer), it will cause a performance hit on many normal preview operations. I agree but it certainly doesn't hurt to allow this kind of use. That's why I say that we need a simple but very flexible widget first. Most plug-ins will never use it's API but access it on a higher level. But if a plug-in wants to do non-standard things, then it shouldn't have to start with a GtkDrawingArea again. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. Sure, but the question is if we expect the small preview area of a plug-in to behave in that way? I'd say the answer is no. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Tuesday 25 May 2004 14:57, Sven Neumann wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews? No, I want to use the GtkScrolledWindow API for the scrolling and the standard GtkWidget API for resizing. What do you mean with the GtkScrolledWindow API? Do you want to actually use GtkScrolledWindow with some image widget inside it that shows the rendered image (that is pretty expensive when the rendered image is large) or do you just want to implement a new widget that has the same API? I want to completely leave scaling out of this first basic widget. It will allow us to get rid of GtkPreview and that's the main problem we need to solve now. Of course it's a good idea to think beyond that and I agree that we will need a more complex preview widget than what I proposed to start with. But zooming is actually a pretty complicated issue, and it will have a profound influence on your API. However this is all not finished and I am open for other ideas. Actually I am not too happy with the proposed API, especially the fact that the buffer is outside the preview and how scrolling would have to be handled. So I am perfectly willing to reconsider it. What is the point about plug-ins that have multiple previews? I fail to see the problem; perhaps you can explain it to me. The point is that when you maintain many important parameters such as size and scale outside the previews you will have to keep track of which data belongs to which preview and you will have to hunt around to find the neccessary data. This is messy. I am currently trying to come up with a proposal for GimpDrawablePreview, an extension to the GimpPreview interface that should allow plug-ins to reuse their rendering function for the preview. One of your main objections against my API was that it would require modifications to the rendering function (because I believed they were pretty minor, that was no problem for me but apparently you thought that this was unacceptable). As an alternative you proposed some alternatives, like temporary drawables and some global mode switch that caused all drawing operations to use a temporary drawable when that drawable was in preview-mode. When you insist that the rendering functions may not be changed at all, you will probably have to come up with something like this. Finding a framework that allows this, should be the major design challenge at this point. It will require some important changes in the Gimp core. This design item will have a very big influence on the preview's API. So why don't you tackle this point first? So far you have not presented a detailed design solution. Instead of finding some quick ad hoc solution for a few plug-ins I would say that it is much more important to get this one right. I am afraid that your proposals so far sounded like horrible hacks in my ears, but perhaps if would work them out in more detail I might be convinced otherwise. Of course, when your real problem is how to add a nice functional preview to a few plug-ins, I know an easy solution :) How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the right size for this buffer), it will cause a performance hit on many normal preview operations. I agree but it certainly doesn't hurt to allow this kind of use. That's why I say that we need a simple but very flexible widget first. Most plug-ins will never use it's API but access it on a higher level. But if a plug-in wants to do non-standard things, then it shouldn't have to start with a GtkDrawingArea again. But an API where the preview simply tells the plug-in give me this area at this magnification is very flexible. When the plug-in decides that it is better to render a larger area and cache it, it can do so if it really wants to. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Monday 24 May 2004 09:26, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. Sure, but the question is if we expect the small preview area of a plug-in to behave in that way? I'd say the answer is no. Why? The primary function of the preview is to preview the effects of certain parameters on the image. It seems only logical that the preview updates as soon as possible after a parameter change. When the plug-in algorithm is fast enough, I see no reason why the preview should not be updated automatically. The only alternative that I see is to have some separate Update preview button, but that is just awkward for the user. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Ernst Lippe [EMAIL PROTECTED] writes: Sure, but the question is if we expect the small preview area of a plug-in to behave in that way? I'd say the answer is no. Why? The primary function of the preview is to preview the effects of certain parameters on the image. It seems only logical that the preview updates as soon as possible after a parameter change. When the plug-in algorithm is fast enough, I see no reason why the preview should not be updated automatically. The only alternative that I see is to have some separate Update preview button, but that is just awkward for the user. I wasn't questioning automatic updates. The question I put up was if there should be incremental update of the preview area or if we can agree that this is not generally useful. In the latter case we can put the progress indicator into the preview area itself. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Agree with Ernst that it's not bad to have the preview widget hold data like other then it's physical limits : - scale - selection limits - ... For instance you can have a plug-in that displays 2 scrollable previews one showing the before and one the after effect. Even nicer they could have to be synchronized(position/scale). The way I see it : The plug-in does the rendering(math) the preview shows it however the preview widget is controlled by the user and knows when it's time to ask the plug in for an update. If one of the rendering parameters changes the plug in should query the preview widget to get it's current view position and render. After warts fill the previews buffer and signal the preview to redraw. 1. a completely passive widget that has no other function then to visualize a preview image. The widget would have a internal buffer where we can put the image data. As with GtkPreview a function gimp_preview_draw_row () would almost be the only visual API for a plug in developer. - Rendering functions do not have to be changed. - only GtkPreview would change to call the new widget. 2. a more actively involved preview widget would have (1) and the basic navigation lets say horizontal and vertical scroll bars. When creating give the widget it size and the current selection limits (x1,y1);(x2,y2) one which a preview has to be made. The widget should have a signal to have it fill it's buffer whenever the scrollbar position changed. A API that returns (x1',y1');(x2',y2') depending on the scroll bars to be used in the callback function or have the values available as attributes. - Rendering functions do not necessarily have to be changed. A call back function wrapped around the rendering function could be used. 3. This would be like 2 but also would have scaling or other features. Geert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Ernst Lippe [EMAIL PROTECTED] writes: No, I want to use the GtkScrolledWindow API for the scrolling and the standard GtkWidget API for resizing. What do you mean with the GtkScrolledWindow API? Do you want to actually use GtkScrolledWindow with some image widget inside it that shows the rendered image (that is pretty expensive when the rendered image is large) or do you just want to implement a new widget that has the same API? Ernst, could you please read my proposal. I said that I want to derive GimpPreviewScrolled from GtkScrolledWindow. Please note that GtkScrolledWindow does not have the fullsized window, it just has the scrollbars and an API that seems to fit our needs. I want to completely leave scaling out of this first basic widget. It will allow us to get rid of GtkPreview and that's the main problem we need to solve now. Of course it's a good idea to think beyond that and I agree that we will need a more complex preview widget than what I proposed to start with. But zooming is actually a pretty complicated issue, and it will have a profound influence on your API. Yes, on the higher-level API but the low-level preview widget shouldn't need to know anything about zooming. However this is all not finished and I am open for other ideas. Actually I am not too happy with the proposed API, especially the fact that the buffer is outside the preview and how scrolling would have to be handled. So I am perfectly willing to reconsider it. What is the point about plug-ins that have multiple previews? I fail to see the problem; perhaps you can explain it to me. The point is that when you maintain many important parameters such as size and scale outside the previews you will have to keep track of which data belongs to which preview and you will have to hunt around to find the neccessary data. This is messy. Outside the preview widget base class which should be suitable for other needs as well. Think about the brush preview in GimpPressionist. This preview doesn't need zooming, it doesn't need a drawable API, it probably doesn't even need scrolling. That's about the level of complexity that the base class should have. Of course a derived class needs to know about the size and scale of the previewed area and I never proposed to keep this data outside of this derived class. One of your main objections against my API was that it would require modifications to the rendering function (because I believed they were pretty minor, that was no problem for me but apparently you thought that this was unacceptable). No, that wasn't my main objection. My main objection was that you introduced temporary drawables at the core side of the wire instead of keeping them in libgimp. Actually I am quite confident that we don't even need them on the libgimp side. We should be able to get away with preview tiles. The core doesn't need to know about them (but we could change that in order to allow a preview in the image window). I also dislike large parts of the API but you designed it before GObject introduced interfaces so there wasn't much chance to get it right back then. When you insist that the rendering functions may not be changed at all, you will probably have to come up with something like this. Finding a framework that allows this, should be the major design challenge at this point. It will require some important changes in the Gimp core. I don't think that any changes to the GIMP core will be necessary. This design item will have a very big influence on the preview's API. So why don't you tackle this point first? So far you have not presented a detailed design solution. Instead of finding some quick ad hoc solution for a few plug-ins I would say that it is much more important to get this one right. I am afraid that your proposals so far sounded like horrible hacks in my ears, but perhaps if would work them out in more detail I might be convinced otherwise. That's why I brought this up on the list. Actually I couldn't care less about plug-in previews but since people are willing to add them and ask me what widget they should be using, I am trying to provide them with the funtionality they need. You had a lot time to bring your preview widget into The GIMP after 2.0 but you remained silent. What else can I do but propose an alternative? The alternative I proposed is designed to allow the widget to be extended later. The goal is to bring it to a point where it does all what your proposal does. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, geert jordaens [EMAIL PROTECTED] writes: 1. a completely passive widget that has no other function then to visualize a preview image. 2. a more actively involved preview widget would have (1) and the basic navigation lets say horizontal and vertical scroll bars. 3. This would be like 2 but also would have scaling or other features. finally someone who understood my proposal :) Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, Christopher Curtis [EMAIL PROTECTED] writes: This is just a random thought off the top of my head, but maybe it will inspire someone... It would probably be very cool if the preview functionality could be implemented so that it could also act as a filter. That's really not feasible to implement with the GIMP image window and the filter plug-in being in too different processes. Especially if you want this to perform in almost real-time. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
I think come up with a simple preview widget is the way to go. At least
all people willing to
add preview's could start doing it the same way.
What I've seen from plugin's is that they are frequently using pixel
regions to render images.
If the pixel region isn't generic enough the I would start with the
functionality described from the current tutorial on the GimpPreview
by Ernst which would be a little more work to implement in some
plugin's. Although I think you should be able to render a bigger
preview area than the displayed area.
Writing a callback for the preview
When the preview want the plug-in to render a new image it will call a
callback function in your plug-in. In most cases you should be able to
use the following:
static void
render_callback (GtkWidget * widget, GimpPreviewUpdateEvent * event,
gpointer data)
{
GimpPreview *preview = GIMP_PREVIEW (widget);
GimpDrawable *drawable = (GimpDrawable *) data;
GimpDrawable *dest_drawable;
GimpPreviewProgressUpdater preview_progress_updater;
/* Get a scratch drawable */
dest_drawable = gimp_preview_get_temp_drawable (drawable, event-image_x, event-image_y,
event-image_width, event-image_height);
/* Initialize the GimpPreviewProgressUpdater */
gimp_preview_progress_updater_init_for_preview (preview_progress_updater, preview);
/* Render to the scratch drawable */
render (drawable, dest_drawable, event-image_x, event-image_y,
event-image_width, event-image_height,
render_params,
preview_progress_updater);
/* Draw the scratch drawable on the preview */
gimp_preview_draw_unscaled_drawable (preview, dest_drawable);
/* Delete the scratch drawable */
gimp_preview_free_temp_drawable (dest_drawable);
}
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, geert jordaens [EMAIL PROTECTED] writes: What I've seen from plugin's is that they are frequently using pixel regions to render images. If the pixel region isn't generic enough the I would start with the functionality described from the current tutorial on the GimpPreview by Ernst which would be a little more work to implement in some plugin's. Sorry, I am not sure if I get what you are saying here. Could you elaborate a bit, perhaps give an example of the API that you think is needed? Although I think you should be able to render a bigger preview area than the displayed area. Again, sorry, but I don't understand this. What's the displayed area? What do you mean when you say render? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, let me try to come up with a list of requirements for a simple preview widget that allows to be extended to a full-featured beast later. - It should be a GtkWidget so that if can be embedded into the plug-in dialog like any other widget. This is not the case with the GimpOldPreview code which returns a struct and forces you to access struct members in order to pack and show the preview. - We will want to add scrollbars and optionally zoom controls. Perhaps not in the very first version, but this should be foreseen. I see two possible ways to do this: (1) Derive the preview widget from GtkTable and put all possibly needed controls into the table. Provide an API to switch them on/off. This is what Ernst Lippe's widget does. (2) Keep the actual preview code in GimpPreviewArea, probably derived from GtkDrawingArea. This is just the preview, no frame, no scrollbars, no controls. Make this widget export the preview API as an interface (called GimpPreview). Then add the following convenience widgets: - GimpPreviewFrame, a sunken GtkFrame holding a GimpPreviewArea - GimpPreviewScrolled(?), a GtkScrolledWindow that holds a GimpPreviewArea (no need for the frame since GtkScrolledWindow draws a shadow already). GimpPreviewArea will have to implement gtk_widget_set_scroll_adjustments for this to work. Later we might want to add GimpPreviewZoom(?) that adds zoom controls but I think it will make our life easier to postpone this for now. All these widgets will provide the GimpPreview interface, so that you can use the GimpPreview API on all of them, without the need to do ugly things such as gimp_preview_set_foo (GIMP_PREVIEW (GIMP_PREVIEW_SCROLLED (widget)-preview), bar); Instead you simply use gimp_preview_set_foo (GIMP_PREVIEW (widget), bar); and don't need to care whether widget is a GimpPreviewArea, a GimpPreviewFrame or a GimpPreviewScrolled. - It should handle RGB, grayscale and indexed data and should provide an API that allows to add other types later. - It should handle an alpha channel. The preview needs to be able to draw a checkerboard pattern below the preview in case the preview has translucent areas. Perhaps we also need a mode that renders on a solid colored background but I'm not sure if that's needed at all. If we ever get around to export the user preference for the checkerboard to the plug-ins, then GimpPreview should handle this transparently, i.e. it should do the PDB calls to retrieve these settings from the core. So what about the API to actually draw the preview? IMO in the first version this should be kept as simple as possible. The plug-in needs to fill the preview with data. It can do this by setting the data row-by-row, column-by-column or in rectangular areas, very similar to the API provided by GtkPreview but also close to the way that most plug-ins operate on the pixel data. In case the preview is scrollable, the plug-in will have to connect to the value_changed signals of the adjustments that it passed to gimp_preview_scrolled_new() (remember that GimpPreviewScrolled is a GtkScrolledWindow). Whenever the preview is scrolled, the plug-in will have to redraw the preview. We could later try to make this transparent for the plug-in and have the preview pull in the drawable data and call the plug-in to render it's effect. But I'd like to implement this later. As you can see, my proposal for now is basically a widget that can replace GtkPreview and implements the common UI code that is duplicated every so often in our plug-ins. It does not yet handle the more sophisticated stuff, it doesn't know about drawables or other GIMP types except perhaps the GimpImageType enum. Later I'd like to see this widget be used by a more complex preview framework. Ideally the plug-in author wouldn't have to write a special function to preview the effect, instead she should be given a pseudo-drawable to work on. That would allow to use the same code that is used on the real drawable. As a nice side-effect this ensures that the preview matches the actual effect. Contrary to the implementation in refocus (http://refocus.sourceforge.net/preview) I'd like this pseudo drawable to exist in the plug-in process only. The GIMP core doesn't need to know about it. This will also make sure that no temporary drawables are left around when a plug-in dies. Alternatively, instead of using an pseudo drawable, we could make the preview work on an extra set of tiles on the real drawable (or rather the GimpDrawable wrapper provided by libgimp since the plug-in never sees the real GimpDrawable object that lives in the core). This would work pretty much like shadow tiles work now only that the tiles would only be flushed to the core when a preview on the image window is
Re: [Gimp-developer] plug-in preview widget (another try)
staring from the back. Again, sorry, but I don't understand this. What's the displayed area? What do you mean when you say render We are talking about a preview therefore the (displayed)preview area is the area that is visible to the user. Will use in for further explanation preview buffer to indicate the non visual area. When I say render I mean the computation of the visual effect. When I say draw I mean the visualisation of the computed effect on the preview area. Sorry, I am not sure if I get what you are saying here. Could you elaborate a bit, perhaps give an example of the API that you think is needed? A minimum for the preview widget would be : Widgets : 1. The preview area 2. Horizontal/Vertical scrollbars if needed. Signals : 1. preview_draw : draw preview area from current preview buffer. 2. preview_update: Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed) API : 1. new_preview_buffer(drawable, buffer, x,y ,width, height, offset_x, offset_y); drawable = self explanatory buffer = type to determine x, y = offset from drawable origin width, height = self explanatory offset_x, offset_y = offset for preview buffer. drawing origin = 0,0 preview origin = 0+x, 0+y x,y=128 width, height = 128 offset_x, offset y = 0 (preview buffer = preview area) = rectangular preview buffer = (128,128) , (256,256) offset_x, offset_y = 20 use to render the preview more accurate. (preview buffer preview area) = rectangular preview buffer = (x1-offset_x, y1-offset_y) , (x2+offset_x, y2+offset_y) = (108,108), (276,276) 2. function to draw the buffer. preview_draw_buffer(buffer); 3. function to free buffer preview_free_buffer(buffer); 4. functions to for internal housekeeping that can be used in the callback from preview_changed. calculate new limits, check if buffer covers new coordinates if not preview needs update, otherwise only draw from buffer. Geert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, geert jordaens [EMAIL PROTECTED] writes: A minimum for the preview widget would be : Widgets : 1. The preview area 2. Horizontal/Vertical scrollbars if needed. agreed Signals : 1. preview_draw : draw preview area from current preview buffer. 2. preview_update: Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed) I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it. Such a framework can be added later as I outlined in the proposal I just sent to the list. The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it. Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Sven Neumann wrote: Hi, geert jordaens [EMAIL PROTECTED] writes: A minimum for the preview widget would be : Widgets : 1. The preview area 2. Horizontal/Vertical scrollbars if needed. agreed Signals : 1. preview_draw : draw preview area from current preview buffer. 2. preview_update: Call-back for rendering function followed by preview_draw or call preview_draw from callback. (if possible send signal preview_draw from within callback to display rendering progress). 3. preview_changed : Call-back to determine which part of the drawable that must be rendered for preview. (after scrollbar position changed) I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it. Such a framework can be added later as I outlined in the proposal I just sent to the list. our posts corssed, agree with You that it can be added later. The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it. as does GtkPreview now, works for me. Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer. implement scrolling by changing the offset into the buffer was not my primary concern but a nice side effect. My primary concern was to be able to render a larger buffer to be as acurate as possible for some plugin's and minimize influence by edge conditions. Geert
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, geert jordaens [EMAIL PROTECTED] writes: implement scrolling by changing the offset into the buffer was not my primary concern but a nice side effect. My primary concern was to be able to render a larger buffer to be as acurate as possible for some plugin's and minimize influence by edge conditions. We can keep the buffer outside the preview widget and only have it create an internal buffer if no external buffer is supplied. The API I have in mind is something like the following: /** * Set a pointer to an external buffer. * * The buffer will be of type guchar* for now but using a gpointer * here allows us to continue to use this API when we introduce * 16bit support and/or floats. **/ void gimp_preview_set_buffer (GimpPreview *preview, gpointer buffer, gint rowstride); /** * Write a row of data to the preview buffer. * * The data is either written to the buffer set in a previous call to * gimp_preview_set_buffer() or if no buffer was set, an internal * buffer is allocated. This API exists mainly to provide an easy * migration from GtkPreview. **/ void gimp_preview_draw_row (GimpPreview*preview, const gpointer data, gintx, ginty, gintwidth); Of course we will want to encapsulate all this at some point, probably be putting a GimpDrawablePreview on top of it. But I'd like to design this thing from the ground up and make sure that it allows a smooth migration from the current preview code. For some slow plug-ins we will also need a way to indicate that the preview is being redrawn. The API could look like this: void gimp_preview_set_progress (GimpPreview *preview, gdouble progress); gdouble progress is a value between 0.0 and 1.0. I think we shouldn't waste screen estate for a progressbar but instead draw a progress indicator in the preview area. Some sort of animation that gives feedback to the user that the preview is being redrawn. As soon as a progress of 1.0 or larger is set the progress indicator stops and the buffer is shown (which should have been updated in the meantime). Does that make sense? Does anyone have a good idea on the animation to draw? I can imagine something like the Mac OS X busy cursor (the b/w one, not the spinning rainbow). To implement this we'd would need a PNG image with all frames of the animation side-by-side. Shouldn't be too large, since we don't want to spend too much time redrawing the progress indicator. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Sven We can keep the buffer outside the preview widget and only have it create an internal buffer if no external buffer is supplied. The API I have in mind is something like the following: /** * Set a pointer to an external buffer. * * The buffer will be of type guchar* for now but using a gpointer * here allows us to continue to use this API when we introduce * 16bit support and/or floats. **/ void gimp_preview_set_buffer (GimpPreview *preview, gpointer buffer, gint rowstride); Sounds fine to me. However if possible a internal buffer in the preview window and the rendering function writing to it would allow redrawing of the preview widget during the rendering process. This would give also some visual feedback on what the rendering function is doing. /** * Write a row of data to the preview buffer. * * The data is either written to the buffer set in a previous call to * gimp_preview_set_buffer() or if no buffer was set, an internal * buffer is allocated. This API exists mainly to provide an easy * migration from GtkPreview. **/ void gimp_preview_draw_row (GimpPreview*preview, const gpointer data, gintx, ginty, gintwidth); Of course we will want to encapsulate all this at some point, probably be putting a GimpDrawablePreview on top of it. But I'd like to design this thing from the ground up and make sure that it allows a smooth migration from the current preview code. makes sense. a litle remark though the *_draw_row usualy itterates over an already rendered buffer. Maybe it's even more simple when migrating from GtkPreview to use the gimp_preview_set_buffer API. For some slow plug-ins we will also need a way to indicate that the preview is being redrawn. The API could look like this: void gimp_preview_set_progress (GimpPreview *preview, gdouble progress); gdouble progress is a value between 0.0 and 1.0. I think we shouldn't waste screen estate for a progressbar but instead draw a progress indicator in the preview area. Some sort of animation that gives feedback to the user that the preview is being redrawn. As soon as a progress of 1.0 or larger is set the progress indicator stops and the buffer is shown (which should have been updated in the meantime). Does that make sense? Does anyone have a good idea on the animation to draw? I can imagine something like the Mac OS X busy cursor (the b/w one, not the spinning rainbow). To implement this we'd would need a PNG image with all frames of the animation side-by-side. Shouldn't be too large, since we don't want to spend too much time redrawing the progress indicator. would be nice, I would prefer to redraw the preview from the buffer reglary if possible. Geert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Sven ignore the previous posting We can keep the buffer outside the preview widget and only have it create an internal buffer if no external buffer is supplied. The API I have in mind is something like the following: /** * Set a pointer to an external buffer. * * The buffer will be of type guchar* for now but using a gpointer * here allows us to continue to use this API when we introduce * 16bit support and/or floats. **/ void gimp_preview_set_buffer (GimpPreview *preview, gpointer buffer, gint rowstride); Sounds fine to me. (IGNORE BAD IDEA However if possible a internal buffer in the preview window and the rendering function writing to it would allow redrawing of the preview widget during the rendering process. This would give also some visual feedback on what the rendering function is doing. ) wasn't thinking clear this would mean updating all rendering functions. /** * Write a row of data to the preview buffer. * * The data is either written to the buffer set in a previous call to * gimp_preview_set_buffer() or if no buffer was set, an internal * buffer is allocated. This API exists mainly to provide an easy * migration from GtkPreview. **/ void gimp_preview_draw_row (GimpPreview*preview, const gpointer data, gintx, ginty, gintwidth); Of course we will want to encapsulate all this at some point, probably be putting a GimpDrawablePreview on top of it. But I'd like to design this thing from the ground up and make sure that it allows a smooth migration from the current preview code. makes sense. a litle remark though the *_draw_row usualy itterates over an already rendered buffer. Maybe it's even more simple when migrating from GtkPreview to use the gimp_preview_set_buffer API. The external buffer sounds fine to me. For some slow plug-ins we will also need a way to indicate that the preview is being redrawn. The API could look like this: void gimp_preview_set_progress (GimpPreview *preview, gdouble progress); gdouble progress is a value between 0.0 and 1.0. I think we shouldn't waste screen estate for a progressbar but instead draw a progress indicator in the preview area. Some sort of animation that gives feedback to the user that the preview is being redrawn. As soon as a progress of 1.0 or larger is set the progress indicator stops and the buffer is shown (which should have been updated in the meantime). Does that make sense? Does anyone have a good idea on the animation to draw? I can imagine something like the Mac OS X busy cursor (the b/w one, not the spinning rainbow). To implement this we'd would need a PNG image with all frames of the animation side-by-side. Shouldn't be too large, since we don't want to spend too much time redrawing the progress indicator. I'll trust You when You say that Mac OS X has nice busy cursors (don't know) Geert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hi, geert jordaens [EMAIL PROTECTED] writes: void gimp_preview_set_buffer (GimpPreview *preview, gpointer buffer, gint rowstride); Sounds fine to me. However if possible a internal buffer in the preview window and the rendering function writing to it would allow redrawing of the preview widget during the rendering process. This would give also some visual feedback on what the rendering function is doing. The preview will be redrawn when you queue a redraw on it. We should probably add a convenience API to do this using the GimpPreview interface. gimp_preview_queue_draw() would simply call gtk_widget_queue_draw() on the GimpPreviewArea. So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On 22 May 2004, Sven Neumann wrote: So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think? There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. There are good arguments for incremental update, and good arguments for a progressbar. Superimposing a busy cursor over the preview or replacing it with a progress indicator makes judging between slight differences in the settings harder. But I think the real issue here is that slow previews should be computed in small chunks in an idle handler so as to not impede interactivity. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hello, This is just a random thought off the top of my head, but maybe it will inspire someone... It would probably be very cool if the preview functionality could be implemented so that it could also act as a filter. Such that, for instance, someone could grab a looking glass and attach an effect to it and move it over the image area. The image within this looking glass would then show a preview of the effect in this area in pseudo-realtime. Maybe if the design is made with this in mind it would make for a very useful bit of code where a 'preview' is simply a copy of the image or layer with a fixed 'looking glass' size and a couple scrollbars. And it would make for some very powerful effects, perhaps even to the extent of having 'effect layers'. Or not. Food for thought, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
