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 <feczo@xxxxx> 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 -><-
