[Memphiz]

With a bit luck popcornmix might get aware of this thread too

For easing the review it might be good to squash those 3 commits down into one. As you already noticed i commented on stuff you reverted in the last commit (with me not noticing in the first place...)

[Memphiz]

@brooc

Just looking at the code (i don't have a rbpi). Have a look at


https://github.com/xbmc/xbmc/blob/master....cpp#L1419

I guess this code is exectured on RBPI aswell and that is the problem. There you see we swap pixels and this also has the startrender, GetRenderBuffer, endrender call (though i am unsure where the second call to GetRenderBuffer comes from).

But maybe i am completly wrong and that code is not hit by the rbpi. IIRC rbpi renderer uses "RENDER_BYPASS" or what it is called. I guess that render flag has to be checked in the method

bool CLinuxRendererGLES::RenderCapture(CRenderCapture* capture)

aswell and should skip the gles rendering (e.x. m_format == RENDER_FMT_BYPASS). You think this could be the root of the problem?

[brooc]

I don't see how it is directly related.
Even if 2 callers call the rendering procedures I don't think this should be a problem.
The delay in light response I see is huge. I mean it could be up to a second of delay in response.
Even if there was some contention due to multiple callers I'd expect it to be much less noticeable...

[Memphiz]

I don't think it is multiple callers ... i think that the CLinuxRendererGLES::RenderCapture just does way to much because it doesn't check the bypass flag. But that is just guessing ...

Would be easy to figure out to add a printout in CLinuxRendererGLES::RenderCapture. If it gets hit - just comment out the whole crap in there but the capture->*** calls (as those are your rbpi implementation which already does all this).