Right then, so a feature request for custom size proxies for images is the way to go, as the mechanism in code for image proxies already exists it shouldn't be too time consuming for a dev to implement, which I mentioned previously.

You say that its not proxy generation anymore that is the issue but size of proxies being equal to project resolution, which is funny as that's what I said previously, twice. :-)

As an aside, stacking multiple pan and zooms I'd hazard a guess will still cause issues with playback with proxies. Not sure if the code for pan and zoom is OpenGL but we'll have to wait a while longer for movit GLSL code in MLT to be transferred to kdenlive, then proxies probably won't be needed at all on a reasonable spec'd machine.

Good luck and I hope you can realize your project with kdenlive.

>You say that its not proxy generation anymore that is the issue but size of proxies being equal to project resolution

You understood me wrong, that was not what I was ment to say.

What I was saying is, that I find it a problem that kdenlive seems to process the whole effect pipeline for a frame in the project's target resolution, making no distinction between final render or 'realtime' preview editing work. This results in stuttering preview. And this is done regardless if you are using proxies as input or not. At least that is my obervation.
And that is what my dirty hack is providing for me: working in a reduced resolution and rendering out in the final one.

>Good luck and I hope you can realize your project with kdenlive.
Thank you :). I think I have found a way to tackle this beast of a project and I am now on a good way to finish it sucessfully.

" ...What I was saying is, that I find it a problem that kdenlive seems to process the whole effect pipeline for a frame in the project's target resolution, making no distinction between final render or 'realtime' preview editing work. ..."

That's why proxies exist and why we can playback h264 video sources in realtime because in fact we aren't we're playing back a proxy of it, whether that be mpeg2, mjpeg etc and at half or quarter size. BUT as I mentioned image proxies do exist, are generated but no smaller than project resolution, that's not what you originally said. :-)

Kdenlive also now has settings in the monitor preview to use lower quality interpolation.

In kdenlives config have you chosen to playback using OpenGL, if not you could try that, also if you're not using a proprietary graphics driver you could try it with that addition, it may help.

"....This results in stuttering preview. And this is done regardless if you are using proxies as input or not. At least that is my obervation. And that is what my dirty hack is providing for me: working in a reduced resolution and rendering out in the final one...."

On my old machine I can add DSLR images of 4k resolution, generate 1080P proxies due to project resolution and playback without stuttering, they wouldn't play at full size, its only when adding effects to the project size proxies that stuttering starts.

So for both images and video proxies are created and used for preview playback including when effects are added and only at render time are the full resolution used, this ia all based on project profile that proxies are enabled for anyone else reading.

So to say no kdenlive makes no differation between rendering output and realtime preview based on your stuttering playback observations is the wrong conclusion, its just that image proxies are TOO BIG. :-)

Yes your hack is a work around, but a simple feature request to achieve the same within kdenlive is the way to go, you don't appear to have got on Mantis and done that?

The time we're bickering over this nonesense a dev could probably implemented it. Its laughable. :-)