Thanks WW. This is extremely helpful. To give you an idea of the improvements that have been made so far, when I first used c2g on the D800 sample, it took 25 minutes for the default! When I optimized it, it took under 1 minute or so.

Anyway, some of the operations are still being heavily developed. As you know, the Gegl operations will replace the filters in the next version.

I will test your scenarios and see what's going on.

@Partha I re-did the Difference of Gaussian and let it go thru without switching programs...and was done in just over 6 mins.

That is interesting considering that edge finding algorithms are probably quite expensive

@Partha just re-ran the Difference of Gaussian, this time without the "preview" mode and timed it on stopwatch...4min45sec

Pixelize ....I ran a 8 x 8 box size on it. Little over a min. It was actually so small I didn't see when it was done...I am guess it was a min

Vignette was zippy just under 10 secs or so

A note about about sliders on these Gegl operations...I am using a tablet...and when I try to slide a value..the slider doesn't move but the numbers indicating the value of change goes into the stratosphere of number land...179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00 ( to be exact) this after trying to move the slider. It didn't move.

I noticed the above for both the Sheer filter, Waves (x,y), translate (originx,y and x,y), transform (x,y), scalesize (originx,y and x,y), scaleratio (origin x,y and x, y), seeing a pattern here... scale (origin x,y and x,y)...

I'll stop there as I need a break

So far, no crashes.

This definitely looks like a bug. Can you reproduce when you have time? If it's reproducible, we can file a bugreport.

Thanks WW!

All righty, here are the results of the sliders with my tablet... a Wacom Graphire 4, Mac OS 10.6.8.

Perlin-Noise ...all sliders fail except last one Iteration
Matting-Global...only one slider here but it is "sensitive" like the "polar-cooridinates" slider.
Grid... all sliders "sensitive'
Fractal Explorer...Width, Height "sensitive"
Drop Shadow...x, y don't move/numbers huge, Radius Sensitive
checkerboard...all sliders sensitive
Shear Origin x, y and x,y don't move/high number value
Waves…x, y don't move/high number value
Translate.. origin x, y and x,y don't move/high number value
Transform… x, y don't move/high number value
Scale size.. Origin x,y and x,y don't move/high number value
Scale ratio… Origin x,y and x,y don't move/high number value
Scale…Origin x,y and x,y don't move/high number value
Rotate… Origin x,y and degrees… don't move/high number value
Reflect.. Origin x,y and x,y don't move/high number value
Polar-coordinates x,y sensitive sliders…they slide but numbers are huge..uncontrollable
Perlin-Noise…all sliders except last do not move/give high number value…"iteration" works fine.
Matting Global.. the only slider does move but no fine control.. is sensitive…it like others goes from 1 to 15230381 (note: this value only from this filter…but this same type problem I've seen in other sliders I've already mentioned.
Grid…all sliders move but are sensitive, don't give fine control over values.
Fractal explorer…Width and Height…no fine control with this moving slider.
Dropshadow…x,y don't move/high number value… Radius slider is sensitive no fine control
checkerboard…all sliders sensitive..no fine control.


*edit... all are reproducible.

WW, Can you file a bugreport so that Mitch will be able to see it?

Thanks,
Partha

When working on high resolution images, I'm experiencing a noticeable difference in the speed at which the image is being refreshed: for example on a 3000x2078 pixel image with two layers, when switching the top layer on on the X11 version, the image is being refreshed within a second. The image seems to be refreshed from the top to the bottom in one smooth movement. On the native version, the image is being refreshed in 17 horizontal sections, one at a time starting from the top, using more than 50% of one CPU core for around seven seconds. This happens both when just using my laptop screen and when using an external monitor.

OS X 10.7.3, Core Duo 2.4 GHz, Nvidia 9600m, 6GB RAM

I can reproduce this behaviour on my system as well. I use a Wacom Intuos (1) but the sliders behave oddly when just using the mouse too.

Great! Can you file a bugzilla report and with details? Then WW can add to that report.

Thanks again,
Partha

I am sorry. I don't know what to do about this. I am limited by what peripheral libraries I have to use.

It is after all the very first native Gimp release (unofficial of course).

I made just two very quick tests, hoping that they can be useful in some way.

Using a 1000x750 pixels image and selecting a 300x300 pixels square, these are the timings.
For the operation "Heal selection" (requiring Resynthesizer):
Gimp 2.6 with X11: 24 seconds
Gimp 2.8 with X11: 11 seconds
McGimp standalone application: 21 seconds
(I found that each time the timing can be a little different, because Resynthesizer draws a random texture and when the random result is more complicated it requires a little more time)

For the operation: Iterative refocus (only on the 300x300 selection), default settings:
Gimp 2.6 with X11: doesn't have the Refocus plug-in
Gimp 2.8 with X11: doesn't have the Refocus plug-in (by the way, glad to have it on the Mac, now! Thank you!)
McGimp standalone application: 1 minute and 14 seconds

Using a 300x300 pixels image and scaling it up to 600x600 (2x) with the operation "Smart enlarge" (requiring Resynthesizer):
Gimp 2.6 with X11: exactly one minute
Gimp 2.8 with X11: 52 seconds
McGimp standalone application: 1 minute and 38 seconds

I have an iMac, 3.06 GHz Intel Core Duo, 4GB RAM

These are good timings. I think it's performing in a respectable fashion.

Thanks Forest. Hope you are enjoying using the native version.

I finally posted a bug report for the GEGL slider issue: https://bugzilla.gnome.org/show_bug.cgi?id=678472.

Interestingly enough, while the filter windows appear behind the main window, the GEGL operation windows always show properly in the front.

Partha, as to the layer responsiveness issue: is this something that I should file a bug report for?

Yes, you will notice that some windows open in front and others don't. Without analyzing every single one, I would have look to through the code to find exactly which ones and why. This would be way too time prohibitive for me at the moment.

[/quote]
Yes, you can. A similar issues exists on Windows too.

Can you anyone on Linux tell me if they have the same issue?

I'll look to add a comment to the bugzilla report. I'll just confirm to this post, I am also having the same problem with my mouse. So is not only the Wacom as I was originally reporting. Interesting to see other users having same issue so just not me.

2.39 Ghz Intel Core 2 Duo, 4GB Ram, Asus N51 Laptop with Mac OS 10.6.8

I love the look and feel of this but it drives me nuts with the no alphabetical order in lists such as alpha, and when selecting images and backgrounds, gradients, and brushes and etc..its really dreadful when you know what you are looking for and know its there...somewhere...but it takes ages to find it because the non alpha order has them everywhere...its like a scatterbrained child....and i am searching just now to see if there is an update with fixes in it...Sorry I dont get to spend much time on the forum these days due to work commitments.

By the way, I am using OS X 10.7.4 at the moment and will soon be upgrading my laptop to OS X 10.8...hope it runs there as well.

Please let me know if it does. That will be great!

Thanks!

Sure Partha I'll be doing that in the next day or two...but oh boy...that alpha thing drives me crazy...patience is a virtue tho so I'm sticking with it...and I need to find time to learn to use some of the other features...I just am so strapped for time these days...