This is just an impression, not a proper observation!

It seems like the new version gets stuck in close-down mode more often.

I do a lot of making and very little rendering. So I'm always loading and unloading newer versions of a CR2 or OBJ. After several of these loads and unloads, the new version won't fully close, and I have to use the Task Manager to end the task.

This sometimes happened in the previous versions, but SEEMS more common now.

I haven't seen such behavior on my machine but I predominantly do renders and material alterations.

Confirmed on my end. But probably that's not the fault of Bondware.

Being still on SM's 11.07.33999, this more often than not happens. Just wait some 20 seconds and Poser should close. Looks like a "legacy" bug.

K

I have seen that behaviour but not only in the latest version. It could be connected to the library running its indexing.

I think Poser hangs a bit when waiting for a drive to spin up.

MacOS Poser has for a long time had a "feature" where idle time required to process other thread (including the shutdown) "hangs" unless there is cursor movement input from the user. If I choose Quit, and then don't touch the keyboard or trackpad/mouse, Poser NEVER goes away. If I keep moving the cursor immediately after Quit, it disappears pretty quickly. This has been a known issue for years, according to Nerd3D. Still extant in the latest 11.3.757 release. Probably something to do with one of the dependent libraries. Fingers crossed it gets staked and reburied with a brick in its mouth for P12.

@FVerbaas: I do not think so because it also happens after Poser has been running for hours.

@ghostship: Improbable because all my drives are set to spin constantly 24/7/365.

@ an0malaus: That's it, exactly! I just wasn't patient enough to wait hours for Poser to close. Yet it often puzzled me why it finally terminated once I moved my mouse over the program GUI (like: I want to run Task Manager...)

Fingers crossed it gets staked and reburied with a brick in its mouth for P12.

Oh: if that happens, I'll gladly donate the bricks. Any number - one for each legacy Poser quirk...

XD

K

Mine has been "crashing" when I close it down, it doesn't exactly hang up, but when the program closes, Windows reports that Poser has stopped responding and wants me to close it even though it's already closed. Superfly rendering also seems to crash my video drivers. Not looking good.

Sounds like a message queue handling problem. Selecting Exit in a Windows program doesn't close the application, instead it will create a WM_CLOSE message in the applications message queue and at somepoint when that reaches the head of the queue the application will close. Poser has the extra complication of having a wx event loop so possibly the two are tripping each other up. Moving a mouse over a window will generate messages in that same queue so may be acting like a pump clearing the queue until the WM_CLOSE floats to the top - just speculation on that part. For a similar reason using the scene.ProcessSomeEvents function stops long running python scripts from appearing to hang poser.

Yes. I have noticed a long "disengagement" time before the program shuts down (windows 10 OS).