LittlevGL is a great GUI library for embedded systems. You can find it at the link below. It can run directly on the hardware or as a component in a system with an OS like FreeRTOS, or even Linux. It has a modular architecture extensible with device drivers for various input and output devices. Typically it drives small LCDs via the SPI bus. I thought it might be useful if LittlevGL could also drive a web interface making use of the same code as a local LCD display without having to go to the trouble of creating a separate web-page based interface. This is the result.
The browser connects to the ESP32 and requests a webpage at "/". The html web page file is stored as a binary section in the program code and returned to the browser by the web driver. The web driver is also capable of uploading a stored favicon file (not shown) and transferring communication to the websocket driver when the web page starts running and requests a websocket connection.
The driver can support multiple simultaneous connections (currently 4) with some performance loss as it has to send the same data to multiple browsers.
Speaking of performance...
As one might image, it depends completely on how much of the screen has to be updated. LittlevGL is good about only requesting updates for regions that have changed (for example a button pressed or text added somewhere). Performance for small updates like this is great. The interface feels very responsive.
Eight-bit pixels require one byte per pixel while 32-bit pixels require 4, a factor of 4 slow-down. This means that updating large areas, for example if there is a background image or if an animation is moving a control across the screen, can get very slow, especially for larger pixel depths. The LittlevGL demo application has the option of including a background image. That really slowed things down. I found that turning it off and limiting the pixel depth to 16-bits resulted in reasonable performance, with slowdown as the animator slid the entire display right or left between tabs (turning this off is better).
I think this driver would be very useful for GUIs that didn't do a lot of animation. Typical control panels with buttons, sliders, text areas and the like should be fine. Sixteen-bit pixels result in good images but if you can constrain yourself to the 256 afforded by 8-bit pixels then you can improve performance quite a bit.