how to switch of the "animate params" ?

[cKleinhuis]

hi there, just downloaded the latest version, works fine, and amazing collection of examples, but ... i would like to switch off the anim feature, it somehow has strange effects,
v0,9,1 i mean ... overall seems to be more stable and speedier

[Syntopia]

Hi,

I'm not sure I understand? There shouldn't be any animation feature turned on by default, unless you press the 'Animation' button?

[cKleinhuis]

when i change values it seems that in beetween frames are shown ... when i re-enter many numbers a whole animation sequence is played in realtime ...

[Syntopia]

If you are in 'Auto' mode, any slider/camera movement will trigger a redraw.

For computationally heavy scenes, you may switch to 'Manual' mode: here the scene is first updated when you press "Update (F6)".

[knighty]

Hi,

I'm having the same issue with the last version. I'm using a low end GC which makes it almost impossible to use 'auto' and 'continuous' modes. In continuous mode, apart from the excellent 'game of life' script, the computer freezes with the others. I also got a blue screen once . In the last version there was no such problem.

Maybe, the best solution would be to use a working thread for OpenGL commands and also use GLfinish() as in the previous versions.

[Syntopia]

Hmmm.

Actually, UI updates does not really trigger render updates - instead I have a timer check every n'th millisecond to see if anything was changed and issue a redraw. So the UI should not be able accumulate render calls. But the previous version of Fragmenatarium checked every 20th millisecond (for a max fps of 50hz) - the current checks as fast as possible (every 1th millisecond - or rather whatever the minimum scheduler granularity is on a given platform).

I've uploaded a new build with a max refresh of 10FPS, and re-enabled glFinish(). Would you mind checking if this improves rendering? It can be found here:
http://hvidtfeldts.net/Fragmentarium-Windows-Binary-v.9.1.9.zip

I'm not sure that using a separate OpenGL thread will help, since I think the reason the machine becomes unresponsive is because of the GPU completely blocking any window updates while executing the pixel shaders. And there is not much to do on the CPU, while waiting for the drawing call to complete?. On the other hand I saw the Qt 4.8 now supports this: http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/

What gfx-cards and OS are you using? Do you also have these problems on the simple 2D systems, like the Mandelbrots?

[knighty]

Thank you very much! That version works very well. The only drawback is that I can't get more than 10fps with simple shaders... One can't get every thing .

I'm using a 9400GT and windowsXP. (Well... I don't use full screen feature).

In the 0.9.1 version, the freezing (and animation -lag- effect) problem occures with 'heavy' shaders: 3D fractals and 2D fractals with high iteration count. For fast shaders It works perfectly. As you said before the driver recieves something like 200 or 300 rendering commands per second while it could render only 10fps. I gess, that's why the game of life shader (for example) works very well, just because it flyes at more than 200fps on my GC.

[cKleinhuis]

i see, hmm ... this sound like a rather time consuming method, i mean the check every parameter for changes, and now we have the problem that changes of parameter arent that smooth anymore

what against an event based update system ? e.g. one element changes fires event "iChanged" and then redraw is triggered automatically

[Syntopia]

i see, hmm ... this sound like a rather time consuming method, i mean the check every parameter for changes, and now we have the problem that changes of parameter arent that smooth anymore

what against an event based update system ? e.g. one element changes fires event "iChanged" and then redraw is triggered automatically

When a UI widget is changed, it just sets a flag on the drawing engine to indicate it needs a redraw, so there is no looping over parameters.

I'll put in a widget to throttle the max fps - this should solve it.

[Feline]

I'd been using Fragmentarium for over a year (v .56 or something like that) and just checked and saw that there's a newer version (several, really) and updated and ran into the same problem.

Even just clicking into the view port and moving my mouse to the side, the screen takes several seconds while I watch it move along the line I expected it to move. There needs to be some sort of check that either cancels pending redraws when new ones are issued or otherwise only issues new ones when previous ones are finished.

When I switch to "contiuous" and then immediately back to "automatic", the program continues to update its continuous activity for many seconds (30 seconds? 45?) before it finally becomes responsive again. When I do the "high-resolution render" thing with a complex DE and I choose 100 subframes, for example, then my log-window immediately fills up with lines "subframe 1 of 100, subframe 2 of 100 ... subframe 98 of 100" while the draw port takes many seconds to catch up and only when it is finished does it move on the next frame.

My graphics card is a Tesla C2070, so it's definitely not a lack of GPU performance that is biting me here. To the contrary, I was wondering whether my card is allowing redraws faster than Fragmentarium expects.

(I wouldn't mind being throttled to, say, 60fps - I don't see that option in the 'current latest' version 0.9.1)

[Syntopia]

Hi, Feline.

Could you try this version, and see if problems persist?: http://hvidtfeldts.net/Fragmentarium-Windows-Binary-v.9.1.10.zip

I will release an new, more official, build soon, but I've been somewhat busy lately.

Btw, your card shouldn't be a problem. I have a C2075 at work, and here Fragmentarium works nicely. My GeForce 570GTX is actually a bit faster - unless you are running double precision :-).

[Feline]

Indeed 9.1.10 works "as expected". Cool - I can live with that :-) Thanks.