Render and add to timeline is back in Edius X but...

[createmedia]

Testing Edius X against 9 I find that render and add to timeline takes 4 times longer in X than in 9 despite walking away from the PC. If it is a background task and no other Edius foreground tasks exist why is it so much slower?

[GrassValley_SL]

Try setting that specific background task to high priority instead of normal.

[createmedia]

Not very satisfactory as it needs to be set to each item that is rendering there is no global setting

[createmedia]

The priority only makes a 7% improvement and of course the render has already started when the priority is to be changed.

The offline media is added to the timeline whilst the render is completing, resulting in the checkerboard being displayed. This is not how Edius 9 worked and in X the media should only be added when rendering is complete.

[PaulTV]

I wonder what the developers are on? Shocking mis -implementation of previous fully working well tested and important functions..who on earth comes up with these "improvements" ??

Still not using X

Paul :-)

[BernH]

I wonder what the developers are on? Shocking mis -implementation of previous fully working well tested and important functions..who on earth comes up with these "improvements" ??

Still not using X

Paul :-)

I am still on 9 as well Paul. Until the quirks are ironed out of X, I am happy where I am. I love the idea of background processing in X, but the implementation is not what I envisioned. I came from Fast/Pinnacle/Avid Liquid. Background rendering in there was exactly that. It rendered in the background, looking for free clock cycles to start rendering, with a time delay that was user assignable, meaning that I could specify a 1 second wait before rendering began to make sure I wasn't doing anything in the foreground. Of course that was in the days of single core or dual core, so the wait was more important, but the implementation was brilliant given the hardware of the day. Exports however were always foreground.

All that said, with current multi-core CPU's and possibly even GPU assist, a similar style of implementation even inclusive of exports would be quite doable, maybe reserving a 2 or 4 of CPU cores or threads for strict foreground use and allowing the rest to be tasked for background use only if free clock cycles are available, or even pushing the background processing to the GPU if it has free compute time. I think something like this would be the absolute ideal, allowing for very good foreground and background use simultaneously.