OpenGL ES, SDL, on weston with VNC enabled

Hi community,
I wanted to share a couple of findings when using OpenGL ES on the colibri with weston.

The configuration is as follows:
I’m using ImGui for the UI, SDL to generate the windows/inputs/etc. running on the Colibri on Weston with Torizon 5.7.0.

I’ve done a few tries and I finally managed to get some nice performances out of it even on 1080p.

The following statistics are done on a 1024x600 screen:

  • SDL with wayland backend, VNC enabled (no connections) → ~10-14 fps, 1 core almost all used by weston, lot of lag on pointer
  • SDL with wayland backend, patched and recompiled as explained below, VNC enabled (no connections) → ~30 fps, VNC broken/distorted, 60% of CPU used by weston, no pointer lag
  • SDL with wayland backend, patched and recompiled as explained below,VNC disabled → ~30-70 fps, mostly around the high 60s fps, 10% of CPU used by weston, no pointer lag

About SDL: I tried other libraries like GLFW but the performances were more or less the same.

The issue seems to be on the OpenGL function eglSwapBuffers on the Vivante GPU: it is very slow and it gets worse fast when the resolution of the screen increases.
The technical manual of the GPU has a list of the OpenGL support extensions and one of them solved the problem and increased drastically the framerate.

Using eglSwapBuffersWithDamageEXT instead of eglSwapBuffers, and specifying the damage rect, tripled the framerate (I directly modified the SDL sources to do this).
I’m attaching a .patch file of the SDL sources with the change.
0001-Use-tiles-and-EGL_EXT_swap_buffers_with_damage-to.patch (3.1 KB)

The damage rect doesn’t seems to matter that much, I’ve divided a 1080p resolution into 9 rectangles that are “damaged” one by one at each frame.

There is no noticeable flickering or distortion on the image on the real screen, but you can see the partially updated rectangles while using VNC, making VNC totally unusable.

Has someone else noticed any high CPU usage while using weston with VNC?
Are there any plans to optimize it?

Thanks

Greetings @mag,

Based on your findings, in summary you’re having issues with VNC affecting the performance of your UI and overall graphics. This seems to happen even when no VNC connection is present just having VNC enabled in Weston already presents a performance drop.

Did I more or less understand you correctly?

Has someone else noticed any high CPU usage while using weston with VNC?

Your findings here are consistent with what we have observed ourselves internally with this VNC implementation. The severity of the slowdown seems to depend on the exact graphics/UI use-case. But in almost every case there is a degree of slow-down observed when VNC is enabled.

Just to understand your use-case. In your end-product will you have VNC enabled always for your system? Is this to have a way to debug/monitor the UI remotely when it’s deployed?

Are there any plans to optimize it?

At the moment there are no plans to optimize this behavior. But given your report and previous reports I’ll see if I can make the case to take a look at this issue.

Best Regards,
Jeremias

Hi @jeremias.tx ,
thank you for the fast response.

Yes I confirm that.

We usually keep it enabled in our other products to provide remote support when needed. Since we are not using any graphical demanding application and lag is not noticeable there (touchscreen so no cursor) it works just fine for that.

It would be great to be able to enable/disable VNC remotely when needed.
The only workaround I can think of at the moment is to keep two different docker-compose releases on Torizon OTA platform, one with the ENABLE_VNC: 1 and one with the ENABLE_VNC: 0 and “update” to the one with VNC only during support.

Anyway, I thank you again for your answer, if there are updates I’ll keep checking this thread and your issue tracker.

Regards
Marco

Thank you for sharing more details about your use-case. It seems pretty normal and sensible to me. Just one more question, is this something you would say is fairly urgent for your product/system or can you work around it for now?

It would be great to be able to enable/disable VNC remotely when needed.
The only workaround I can think of at the moment is to keep two different docker-compose releases on Torizon OTA platform, one with the ENABLE_VNC: 1 and one with the ENABLE_VNC: 0 and “update” to the one with VNC only during support.

I believe your assessment here is correct, you need to restart the container to change the VNC configuration.

Best Regards,
Jeremias

Hi @jeremias.tx,
we can work around it for now.
We will probably start rolling it out to customers at the beginning of the next year and it will take some more time to “ramp up” the numbers (hopefully).

Regards
Marco

Thank you for letting me know, it helps with our own prioritization and such. Well as you said for the time being this isn’t an immediate issue, but I’ll try and inform you of any improvements or progress we make here.

Best Regards,
Jeremias

1 Like