I was thinking abiut the subject , and came to
a way of doing it - if PDB calls can be made normaly
from inside these plugins - which I assume thay can, without problens.

Therefore, if you will allow me, I will describe what I was thinking in
"gimp pseudocode". Someone more familiar to the core than I could tell
me if there is a fundamentla flaw. If it allright, than I think it could
be implemented in less than a couple of weeks:

In summary before for performing a preview in such filters, this could
be done:

1 - Test from viewing window and scale, and from memory avaliability,
if it's worth to use these optimizations.

2 - Create a new image - new drawable if we are working in a single
layer image, or top visible layer in "normal" mode.

3 - If the current selection is larger than the viewable area store it
somewere, and intersect it with the viewable area

4 - if the image is "zoomed out" copy all visible layers to the new
image created, and scale it down in "linear" mode, in a manner that each
pixel in it is equivalent to a pixel on the screen at the subject image.

5 - perform the filter action ont he corresponding layer on the new image.
6 - "copy visible" the new image
7 - create a new temporary drawable on top of all visible layers on
the subject image
8 - paste draft image visible contentes on new drawable, position
and scale it accordingly.

9 - repeat 5,6 and 8 until the filter is commited or cancelled

10 - restore selection, delete temporary layer and temporary images
11 - commit changes.


What do you think about it? Of what I've seen on the code, it seens that each such filter does it's own changes on the images. They all would have to be individually modified to use the steps above. Still doesn't seen hard:

a - if filter is in "preview mode", calls a procedure that makes steps 1
- 4 above,
and return a new drawable.
b - perform filter action on drawablem and call  a procedure that will
perform
 5, 6,7 (once) and 8 above.
c - on ok or cancel, call something to make 10, and perform 11


Feczak Szabolcs wrote:
Feczak Szabolcs <[EMAIL PROTECTED]> writes:

Changing the color balance/brightens-contrast/ color curves are
significantly slower in gimp vs. photoshop on the same machine.  The
problem is not the processing time alone, but the preview takes the
same amount of time as the final processing.  I have relized, that
gimp calculates all the data in preview mode as I would have pressed
the ok button.

Very well spotted.



Other good idea came from my friend: creating a smaller image in
memory, which has the resolution of the screen and calculating the
preview on that image.

That is obviously the approach that should be taken.


AFAIK, there are no plans to do such an improvement. Considered that
we still lack some funding for our developers conference this summer,
perhaps we could be persuaded to give it a try.


Ok, what do you need to be more persuaded ?




        JS
        -><-


_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to