How to understand if frame buffer has changed with TouchGFX lib

[Danix2k]

Hi,

I have integrated with lwIP and freeRTOS a VNC server on a STM32H757-EVAL.

A VNC client works fine and I can see on it the first frame buffer drawn by the application; according to the VNC standard, the server should send a "new tile" (a square of pixel) to re-draw the frame buffer changed (if something happens and change it - i.e. slider, button clicked, etc..).

Is there any function or method to understand which pixel (or pixelS) has changed (in term of X and Y coordinates) from the previous frame buffer?

In this way, I can recreate a new tile and send it to the VNC client without re-send every time the whole frame buffer using less bandwidth.

Thanks for your help.

Regards.

[ktrofimo]

Sorry for the late reply...

Code is still too dirty and full of hacks and I am not ready to publish it. Basically it is the same ECOS VNC server code where OS functions ported to the corresponding CMSISv2 functions.

[JureL]

Thank you for reply. Is this the source code you started from :

https://github.com/kaos/ecos/tree/master/packages/net/vnc_server/current

?

Regards, Jure

[ktrofimo]

Yes, this is it.​

[ktrofimo]

vnc-server and vnc-mouse are only files needed since I do not need a hardware keyboard support and no drawing/printing functionality is needed because TouchGFX does all graphics​.

Please note that killing framebuffer task the way it is written here will kill whole FreeRTOS, so I just suspend framebuffer task functionality when VNC is not running.​

And if you have double framebuffer ​strategy for TouchGFX then make sure you are reading correct framebuffer.

I use RGB565 color space and only VNC client I was able to use is RealVNC.​

[JureL]

Thank you. I will give it a try. I already implemented fully working vnc from stemwin lib with touchgfx. It works with real vnc and any other client. However, I have problems with the vnc server freezing up occasionally and not being able to connect again until I reset the board. It freezes in a process that is part of the stemwin lib, which is very difficult to debug.

Regards,

J

[ktrofimo]

Ecos code is working now for 12 hours and at the moment have 30GB of data received. No hang ups during session.