azul
azul copied to clipboard
fschutt
Support for raw framebuffer
Is it possible to compile Azul without X11 and Wayland support, and draw to &mut [u8] instead?
I want to use Azul to draw a GUI at embedded device (iMX6). Device has 5 buttons only, so it need no support for mouse, touchscreen, X11, or Wayland. It need just to show predefined frames with data, such as splash screen, menu, labels, inputs, on screen keyboard overlay, etc.
No, that's not possible currently. It's way, way too early to think about that, Azul was not made to run on embedded devices, this is out of the scope for this library, sorry. Use Qt instead.
Respectfully, I think that while it may be too early for such a feature to work it should absolutely not be considered too early to take this into account or explicitly rule it out. Architectural decisions are going to need to be made that will affect how easy or hard (or even impossible) it's going to be down the line - having it as a long-term goal or non-goal of the project will greatly help in guiding decisions.
I'd say this is definitely a non-goal. Azul uses webrender as the backend and that works on top of OpenGL 3.x. This library was made with desktop applications in mind, so embedded is out of scope, like fschutt said.
Note that OpenGL is not a blocker for embedded. If using the OpenGL ES profile, most modern chips with on-board video acceleration are fine.
Well, as it currently stands, there is nothing that largely prevents a software renderer, besides the fact that it's a ton of work. I've seperated azul (the global package that includes webrender and winit / window handling and is intended for rendering on desktop + mobile) from the azul-core algorithms (such as layouting, diffing, painting order, font and image garbage collection, timers, tasks / threading, caching, etc.).
In order to support raw-framebuffer access, you'd only have to write a software implementation that takes a CachedDisplayList, renders it and handles input events. Maybe rewrite it a bit to efficiently handle scrolling / transformations and you'd probably need to get rid of the CSS engine and directly attach styles to each DOM node instead. But that's about it, everything that the GPU does can / could be emulated in pure software (without OpenGL or software-OpenGL LLVMpipe).
Right now on Linux, the memory usage for an azul app is about 13 - 17 MB. So maybe, with a small linux distro, you could get away with a 64 or 256MB RAM device if it runs at least OpenGL ES 2.0. But I'm not sure if azul compiles on ARM architectures.