Remnant of FS25 - Pause button hard to hit if animation at a few FPS.

[wfpokorny]

http://bugs.povray.org/task/25

Pause button hard to hit if animation at a few FPS.

---

Details:

There is an issue where the pause button in POVWIN will sometimes not work during an animation (primarily where the frame rate is high), and furthermore, POVWIN can then get into a state where it's not possible to use the pause until it is re-started.

http://news.povray.org/povray.beta-test/thread/496e9720%241%40news.povray.org

---

Comments:

---

Comment by Thorsten Fröhlich (thorsten) - Tuesday, 23 August 2011, 11:49 GMT+5

What is the status of this?

---

Comment by Chris Cason (chrisc) - Tuesday, 29 January 2013, 05:30 GMT+5

    Field changed: Due in Version ( -> 3.70 release)
    Field changed: Percent Complete (0% -> 90%)

The issue with unrecoverable state should be fixed as of RC7.

I have not yet addressed the pause button being hard to hit if the animation is hitting a few FPS; I've left this task at 90% due to this.

[wfpokorny]

The original issue was reported on windows vista. I run on Ubuntu 16.04 so was unable to test the current POV-Ray 3.7.1 (commit 3cd6b6c) on windows.

I did spend some time running the /scenes/animations/splinefollow demo scene trying pauses with the p-key on linux. It is often enough hard to activate the pause.

The less than grand news is while pausing and un-pausing the animations, I once ended up with POV-Ray hung in a state where the console comment said it was rendering, but the program was in fact hung. Unfortunately, I was not running instrumented code and I've not been able to reproduce the hang since.

The hang is similar I think to what was happening more often before the closed :

http://bugs.povray.org/task/23

Aside 1: At least for me, issues with window updating continued occasionally after the FS#23 change sometimes rippling into other programs like gimp after first showing up in POV-Ray. Sometimes the updates would clearing up magically, sometimes only after re-starting.

Aside 2: I have been looking a little at Simple DirectMedia Layer Version 2 due the reason above among others. Version 2 though requires code updates as the API changed 1.2 to 2.0. It's got some cool stuff in it.

Aside 3: Our configure library test is: libSDL version >= 1.2 which I think should be >= 1.2 & < 2.0 given the 2.0 API is not compatible. This OK. Turns out there are separate SDL provided test scripts for 1.2 and 2.0.

So... Stuff going on with pausing animations on linux no matter whether still an issue for windows users.

We could dig deeper into why our current SDL1.2 has issues including some alpha display differences to the rendered output file I have never reported because I've never run them down to a good small test case. I started to look at SDL 2.0 because I don't think it makes sense for us to chase old SDL 1.2 issues.

Thoughts?

[wfpokorny]

Today I was able to get POV-Ray to hang running an instrumented version of the code. Ubuntu 16.04.

I was testing again an animation, but turns out this hang happens just from hitting the 'p' pause key frequently while rendering the first frame. The instrumented code is much slower.

I think we have some inter-thread race condition. I'm still looking at the code and stack trace and will post again if I figure out more.

In the meantime, if anyone more experienced with threads wants to take a crack, I have attached the gdb info & all stack traces from the hung state. Lastly, I was able to get out of the stuck state by switching into thread 2 and forcing a return from:

SignalHandler () at unix/unixconsole.cpp:98

debuggingPauseHang.txt

(2hrs later) Finding this issue hard to reproduce. Not yet able to get another hang with instrumented code. Only once with a regular compile. Comparing working pause (DBG code) with a hung state above is mostly similar except I must have missed the thread 7 stack trace above. Hang I got with the regular compiled code would switch between paused and rendering console messages, but never really return to rendering. On ctrl-c to stop got the interrupt message, but program didn't exit to the console and I had to issue a sigkill to the povray process. Confused. I'll keep digging as the mood catches me.

[wfpokorny]

Managed to get another hang with a non-debug compile and traces before and after an ignored cntl-c. I now think we have the mutex deadlock situation due our unix signal handler described at:

http://www.linuxquestions.org/questions/programming-9/locking-mutex-in-a-signal-handler-function-789218/

I'm tempted to comment the boost::mutex::scoped_lock call in the unixconsole.cpp SignalHandler. It's there I guess to protect the gSignalNumber global variable. Wondering why isn't it ok to just let sigwait set gSignalNumber directly it is active in just one thread... Guess I can play with these ideas, but given how infrequently I'm getting into the deadlocked state it will be hard to know if I have fixed the issue for certain.

Anyone more experienced with threads and mutex locking feel free to offer advice!

[wfpokorny]

I've broken out the mutex deadlock issue as github issue #142.

Please now limit work and comments here to that of high frame rate animations being hard to pause.

Thanks.

[c-lipka]

@wfpokorny Can you give a short TL;DR of the current state of the issue?

[wfpokorny]

Original issue was on windows and I don't run windows. Someone else needs to test there.

I'm able to pause OK on Ubuntu for frame rates of up to 20/sec(1) using SDL2.0 or X11. Even the original look with SDL1.2 was 'OK' as I recall for pausing - if not ideal. You do have to hit 'p' more than once sometimes when the frame rate gets higher, but I was always able to pause.

(1) - As a usage note, the preview window needs to have focus to pause / un-pause.

I'd broken out the the hang as another issue and just now suggested it be closed after rambling a while - on the assumption v4.0 will in the near term move to an SDL2.0 / X11 display - or support both. I've not seen the mutex lockup with other than SDL1.2.

[c-lipka]

@chris20 Did you ever find the time to address the hard-to-hit pause button issue? If not, would you consider it worthwhile trying to address this in v3.8?

[wfpokorny]

FWIW. While working on a unix/linux only patch for #142 in my povr fork, I noticed furiously hitting the pause P or p key will only make pausing less likely - and thread deadlocks more likely. Slower, steady attempts to pause 'p' will work better. This at least true with the unix/linix window preview code.

This issue originally submitted for windows builds, so might - or might not - be that slow and steady is better with windows.