Update for anyone who is curious, plus a word to be wiser than I was and read the manual more closely than I originally did!!!:
Original issue:
Updating imagestim characteristics (location, size, opacity) on every frame in some of my routines was extremely memory intensive, leading to jittery animations online.
I eventually figured out that even the offline version was also dropping frames (even though this had fairly little visual impact in PsychoPy). Online, on Pavlovia, I was getting hundreds of ``[Violation] ‘requestAnimationFrame’ handler took ms’’ warnings. In fact, on a few Pavlovia pilot runs, (2 out of 7 computer/browser combinations I tried), similar issues (WebGL context lost errors) were causing the experiment to completely crash.
My questions above:
Indeed, I’m pretty sure these issues did come from dropping frames. If there were a way to do fewer frame refreshes per second, I bet that would have an impact on these memory issues. But, as the manual clarifies nicely, I don’t think there’s any way to set frame refresh rate manually on most computers:
Section 2.8.2 (page 17):
Most monitors have fixed refresh rates, typically 60 Hz for a flat-panel display…
…[with the exception of] the caveat…that you can now buy specialist monitors that support variable refresh rates (although not below at
least 5 ms between refreshes).
Since the majority if not all of my participants won’t have this special hardware 
, and now that I understand the source of my issues better, I have opted for other fixes.
What actually worked?:
I made the following changes to reduce the memory issues that this code was creating, which has stopped the crashes my piloters were experiencing.
- First, inspired by this post (Browser issues: exp runs online using Mac, but not Windows), I stopped updating opacity on every frame. (Since I’m already updating image size on every frame, I just changed the image size variables to 0 under the same conditions in my code snippet, and made opacity constant).
- Second, based on the following advice in the manual, I reduced the number of pixels to just enough to not look grainy at the typical size they occupy on a normal screen. (I created my stimuli images myself in Adobe Draw, and had left them at the original whopping 1024x768pixels resolution…
) For those using Preview on Mac, this is under Tools > Adjust Size on the menu bar.
2.7.2 Tips to render stimuli faster (page 14-15)
- Keep images as small as possible. This is meant in terms of number of pixels, not in terms of Mb on your disk. Reducing the size of the image on your disk might have been achieved by image compression such as using jpeg images but these introduce artefacts and do nothing to reduce the problem of send large amounts of data from the CPU to the graphics card. Keep in mind the size that the image will appear on your monitor and how many pixels it will occupy there.
- Finally, I had (rather foolishly) included a few trials that didn’t need any animation under a routine that did check all of these image attributes on every frame (I had just set those variables to constants in my code snippets). I created a new routine with constant image stim attributes and moved these trials into this new routine.
I hope this helps anyone with similar issues!