Rockbox

can you track down which commit did it?

Not at the moment, but I should be able to later today. I will get back to you when I have.

OK, I have narrowed it down to somewhere between 26713 and 26719. Considering that the only commit in that range that actually affects PictureFlow is 26713, I am reasonably sure that is the one that caused the problem.

cheers.
can you roll back to 26712 and try patching each of the patches from http://www.rockbox.org/tracker/task/11270#comment35882 starting from #2? I would guess #4 would be the problem...

No doubt it's #6 - audio_dropouts patch. This one inserts new yields in the rendering loop.
On Fuze this improves the smoothness and prevents audio from dropping out when scrolling quickly.

If the problem is visible in USim then I could try finding a fix. I have no Nano2G to test.
That patch is worthwhile for Fuze targets as it improves both scrolling and audio playback.

If it's a matter of the Nano2G not being able to handle the increased yields then perhaps try adding a condition around the 3 lines inserted at line 1807 so that it yields less often. eg. if( x % 10 == 0 ) { ... 3lines }. I did this during testing on Fuze but it worked the same or better without it. It doesn't need to yield so often but yielding more than once per render makes a marked improvement.

I was thinking it was probably #6, too. Why not just put an #ifdef around it so it only applies for the targets that need it?

I'm ok with an #ifdef but I don't have any idea what targets have problems or not. I wouldn't want it to be a big messy thing there.
I mean for the time being it could be #ifndef for nano2g b/c we know that has problems. But if more deviations turn up we should figure out what underlying cause (if one) makes it a problem.

Did you try running with those 3 lines removed to see if PF returned to past behaviour? I can make a patch for testing that if need be.

Yes, removing those four lines does cause it to return to normal behavior. I don't understand why it doesn't work well though, since (I think) the Nano2G is one of the more powerful targets...

Try leaving the yield line in place but commenting the two following lines that resync (bmp = ... , and ptr = ...). The surface line can cause loading a file at a point which may introduce a visible delay. Disabling those may smooth the display but cause visible glitches to appear. If that helps then I'll look for a better approach for that.

Michael,
Can please test this patch?
It still works fine on my fuze but cuts down yields by 10x.
I tried some other methods here but none were smooth and glitch free.
I suspect on the Nano2G must have higher overhead on memory mgmt and/or task switching.
Let me know if this improves a little or a lot.

With just the patch, it still runs jerkily (though less so than without it.) I am now trying removing those two lines...

With the resync code commented out, there is no visible difference from just the yield-test patch.

I'm thinking the added yield was an incorrect fix.

On my fuze, you can get drop outs when scrolling slowly too, and it is loading slides (loading happens in a seperate thread, so it yields). That means the audio thread doesn't run even though there are yields.

Indeed, decreasing the priority (tested with PRIORITY_BUFFERING) of the loading thread let's pf run less flaky and without audio dropouts. I cannot tell if loading slides takes longer or not though (but I suspect it does).