Windows. Vista 64bit, Intel Q9450, 8Gb Ram. Poser Pro 2012 64bit.

I am wondering if something is not right:

Windows Task Manager (and SysInternal's Process Explorer) report that the Poser process is using and not releasing huge numbers of Handles. For example, after a heavy hour or two of use; there can be over 300,000 handles. They don't reduce, unless I Quit, and restart Poser.

The high number of Handles does not reduce after clearing the cache, or simply starting a new project. Only by restarting Poser.

I can't claim that I notice any loss of speed from these huge number of window's Handles; but wonder if these is something wrong with Poser's ability to close unused handles.

That's been a problem with Poser for a few versions. I don't run it for more than a few hours, then I save and restart. Sometimes it even starts going wonky on me.

Laurie

Just out of curiousity, what kind of handles does ProcessExplorer show as being open? Are a lot of them file handles? If you run SysInternals FileMon when starting Poser, you can see it hittling all the files in your runtime as it populates the library. I wonder if it's keeping all of those open.

I don't know if this is relevant or not, but yesterday, when I was timing renders, I rendered one scene several times.

I rendered a scene a few times to test it and get the render settings where I wanted them. Then, when I timed it, the IDL portion of the scene took 71 seconds.

After I quit Poser and restarted, the IDL portion of the exact same scene with the same render settings and dimensions took 43 seconds.

The next attempt took... 43 seconds.

The more renders I do the more it slows down :P Especially if I'm cancelling a lot of em.

Laurie

Quote - The more renders I do the more it slows down :P Especially if I'm cancelling a lot of em.

Laurie

Well, I'm glad I'm not the only one who seems to have noticed this. :)

as far as I can see, a Poser render uses 1000 handles, say 300 in prepass and 700 in render (*). When rendering as a separate process, each render leaks 300 handles on the Poser process, the other 700 are returned when FFRender shuts down. When not rendering as a separate process, each render leaks 1000 handles on Poser.

Some older sources on the net suggest a max of 10.000 handles a process, but my impression is that they refer to something different. Mark Russinovich (http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx) reports say 16,000,000 max handles systemwide requiring 256Mb storage for a 64bit system.

(*) I don't know to what extend these numbers are determined by rendersettings (SSS/IDL), imagesize and bucketsize, but 700 is not that far above the amount of buckets in my render. Just wondering how you get to 300,000, Poser itself with a simple scene and no renders or any actions took 750 handles, +100 for flagging the SR2.1 update available now.

Anyway, render in separate process (or background or queue manager).

Thanks for your responses. I have now emailed SM and reported the issue.

Given my past experience of their Support system, I don't expect much; but I shall post an update if they are able to explain or solve the bug.

SM's Support appear to accept that excessive Handles can occur when running the Renders in Poser's process. Changing my preference to Render in a separate process removed the problem (and as suggested in the post from aRtBee) immediately.

One of the undocumented effects of Rendering in a separate process is the 'Base Priority' of the rendering engine. When run in Poser's process, it runs at 'Normal'. But, when ran as a separate process, it uses "Below Normal". SM are now aware of that issue.

In effect, if the PC is busy (e.g. doing a Queue Manager job); and the User wants to Render 'in a separate process'; then the render will take a long time to complete - as it has the same priority as any other instances of FFRender.

@timarender

are you sure? If I launch Poser in Normal state, then my FFRender runs in Normal prio as well. However, this BelowNormal Prio is preferred anyway, otherwise your network, youtube etc will stop, and so on... Personally I run Poser itself in reduced priority so I can watch the EK Soccer games on my other monitor :-)

The best thing to do is to launch QM in Lowest priority, then its FFRenders run at that as well, and your own FFRender gets prio over that.

I did a (multi post) tutorial on things like this, check out my Missing Manuals site. You may know most of it but it might contain some useful tips. Short route: http://www.book.artbeeweb.nl/?p=169 but check some other posts in that series too.

May we clarify. I have one PC.

a) When running Queue Manager, that EXE runs at at 'Normal'. That is suitable to me.

b) Whenever Queue Manager starts an instance of FFRender, those separate processes run 'Below Normal'. That is suitable to me.

c) If I render from Poser, asking it not to render in a separate process; then the effect in Task Manager is for the Poser exe to run a high CPU in the Posers 'Normal' process. And no separate process is visible. That makes sense to me.

d) If I render from Poser, asking it to render in a separate process; then Task Manager shows the temporary instance of a FFRender process. But, that process no longer runs in Posers 'Normal' setting. On my machinem that new process is always set to "Below Normal".

Quote - d) If I render from Poser, asking it to render in a separate process; then Task Manager shows the temporary instance of a FFRender process. But, that process no longer runs in Posers 'Normal' setting. On my machinem that new process is always set to "Below Normal".

This was a much requested feature. It allows you to browse and do other things without the slow down which a 100% CPU usage would bring. If you leave the machine idle, the render engine will take all CPU cycles

indeed!

PPro 2010 is launching FFRender in Normal mode, PPro 2012 does so in BelowNormal. I hardly noticed as my PPro2012 itself is launched in BelowNormal, but that is not necessary anymore. Undocumented feature, I like it. I'll adjust my tutorial on this.

But for QM to launch FFRender in Low, it should be launched itself in Low (a process cannot launch a subprocess at higher prio than itself). This is to render at lower priority than the "regular" FFRender, to avoid timarenders "render collision" issue, plus to avoid his extreme growth in handles as he still can render as a separate process with good response.

If you want to experiment:

What do you think this means: RENDER_PROCESS_PRIORITY 1

This is in the poser.ini. My guess is 0=low, 1=below and 2=normal, etc

Experiment at your own risk