Has anybody got this filter and how is it used? I read this on here http://www.gimp.org/ it's free to download it's zipped, tar formated. Once you have downloaded it where dose it go anybody has any idea?

GEGL is built in to current versions of GIMP. It's under the Tools drop down menu.

edit:

Did download the files, but they are .c files and have not been compiled yet so they need to be compiled otherwise the files are useless. I don't know how to do this for Windows OS.

Yes Lyle is correct.GEGL ops are all setup in Gimps tool menu.
For instance here is Fractal explorer.

Rod & Lyle: How well does the GEGL ops work on your machines? In Linux they seem terrificly buggy.

Very slow especially the blur filters.Other than that on Widows XP they seem to work fine.
I rarely use them however.I wish it had a tool for composing and decomposing channels.

Other then C2G, I rarely even run them Mahvin. I do remember a few GIMP versions back that some GEGL operations would crash GIMP 32-bit (in Win7 64-bit which is where I use GIMP). Still, I did try a few of the operations in 2.6.10(and 11) and they seemed fine; still slow. If GEGL suppose to be the main engine where GIMP runs in, then I'm not looking forward to the future. lol

My thoughts, exactly, Lyle. GEGL seems like an anchor not an engine.

LOL, I tried running something (don't remember what it was) and the next thing I knew GIMP had crashed, kerplop, no GIMP.

Had a look in Gimp and used it but crashes when in use

I don't use them that often (except C2G) but I don't remember seeing one crashing Gimp. And the blur filter is about as fast as the standard one, the only difference is that instead of updating a progress bar and display the whole result at the end, it updates the screen on the go...

Gimp v3 with GEGL use floating point instead of short integer arithmetic. This is going to be slower, but then we will lose less time trying to fight the side effects of the short precision of the current version.

I'm not so certain that FP will be slower on most modern hardware. With dedicated FP hardware (such as SSE), addition and multiplication occur in a single cycle (same as integer), and while FP division and higher order functions take longer, they are typically faster than with integers. Of course, FP will require a lot more memory and this will have a negative impact upon the processor's memory caching; but then a lot of current libgimp arithmetic involves operations on individual bytes and this has a negative impact upon the processor's instruction lookahead parallelization (the lookahead optimization usually gets blocked when non-word-sized operands are encountered, whereas for word-sized operations the next few instructions can potentially be executed in parallel to the current one).

I'm not sure how it will all wash out (and if you care to instruct me, I'd be glad to be enlightened) but I get the feeling that the days of integer ops being faster than floating are over. ... and then there is the potential for OpenCL (which we should've had a decade ago had the graphics card vendors been more open with their hardware).

I have not experienced a crash yet (Windows XP 32 bit)
Just slower than all get out running most of them.

maybe some crazy setting are causing that ^
Note that is very esy use crazy setting when using for the first time a unknow operation wich paramethers have cryptic label,
And it is not impossible that some GEGL operation have "crazy settings" as default because many developer don't give too importance to the default

I have this doubt because GEGL never crashes when i was using the operation that i know. but it did several time when i try unknow operations


another cause ,maybe the first, of crashes is impatience:
the filter require some time to produce visible result but the user fear gimp frozen or anyway can't wait without doing some extra clicks (as on the image windows hoping a extra click will speed up rendering, or on UNdo to try to defreeze)

But that "extra " clicks are possible reason for crash, gimp was busy doung something, then you give another order now gimp has to handle 2 orders that can be conflictual,and anyway ca)n't be executed simultaneusly
Often there are Locks preventing this (you will have seen a error message as "Gimp can't run 2 plugin or script simultaneusly,... ") but since gegl operations are still experimenthal maybe they don't use yet a similar way to deal with this users errors

I believe this can't be a probable reason for crash, at least happened once wth c2g...while waiting i secided to play some music but for some reason the mouse pointer focus was not on VLC the player that i was keeping on top,on a gimp window below, that extra click crashed gimp

uff too long message

In few words first AVOID to click somewhere if gimp seems frozen, extra clicks will not help to defreeze but may cause crashes even if everything was going well,and gimp was not freezed but just busy

And i bekieve the only gegl operation that may cause crashes are the less know, because in that case is easier chose wrong parameter, where for wrong i intended that will use too much computeres resources.

I actually always wondered about GEGL and have been going to ask for some time...so now I have fiddled with it after reading this...no crashes as yet..havent really figured out what I would use it for but will give it a run soon...I liked some of the effects I have seen.

Akky
Most of Gegl operation are just equivalent of the normal one with the same name (usually in fiilters or colors) the difference is that are a examples on how port old filters to gegl and most relevant for average users have a option to get the preview applied on the image

Then there are few that propsed something new that has no equivalent in the "Normal" filters as c2g

Not neccessarily. GEGL can do mipmaps.