GNOME Bugzilla – Bug 759208
cluttersink: Never render on slow upload
Last modified: 2015-12-10 14:42:42 UTC
When uploads get slow enough nothing is ever rendered. This is because the upload source has higher priority then the renderer. As we endup always having an upload pending, we never render anything to screen. Priority should be given to renderer (note rendering require multiple messages).
Created attachment 316974 [details] [review] video-sink: Ensure uploaded frame are displayed This is fixed by making the uploading source lower priority than the redraws. This is important, as Texture2D upload on slow memory system can take a lot of time. You still want your UI to be responsive (being able to show controls, resize, etc.)
Created attachment 316985 [details] [review] video-sink: Ensure uploaded frame are displayed This is fixed by making the uploading source equen priority to the redraws. This is important, as Texture2D upload on slow memory system can take a lot of time. You still want your UI to be responsive (being able to show controls, resize, etc.) and not spend all the time uploading. Ideally, we want exactly one upload per render but we don't have that much control. A lower priority makes the video jitter when there is overlayed animation happening.
Review of attachment 316985 [details] [review]: Ok. Just out of curiosity, what kind of device are you having issues with? RPi?
It's an Amlogic S805. In 720p with an HW decoder that produce RGB32, nothing ever get rendered as it's uploading in loop. I suspect this will never be seen with SW decoder, as decoding becomes the bottleneck. It remains that as soon as the copy done in Texture2D (in the GL stack) becomes the bottleneck, the chosen priority will cause the rendering to starve. In an ideal design, we'd find a way to guaranty that everything that get uploaded also get rendered, so we don't waste all this effort.
Review of attachment 316985 [details] [review]: Pushed to 3.0 branch.