Integration into non Azul programs

[nico-abram]

Is there (Or are there plans) to be able to use azul within a non-azul program? (By just using software rendering and getting a texture to render, or doing something similar to what imgui does and just provide a function to execute DrawCommands through a renderer of choice)

I'm also a bit curious if it'd be possible to use azul within wasm.

[fschutt]

• Azul currently renders the output of every window to a regular OpenGL texture (code here). The problem would probably not be "how do I get the output texture", but rather "how do I make an API to send input events". In the lastest changes, Azul has migrated away from "events" and rather uses a diff between the last and current window state in order to determine what input events happened. The main function to send events to azul is here. So, in theory, all you'd have to do in your application is:

  1. Initialize the necessary caches (Azul caches DOM, CSS, callbacks, text layout, etc.) - however that's just a few function calls.
  2. If there is an input event, update the FullWindowState for the window and then tell Azul that the window state changed like this
  3. Either call the callbacks yourself or let Azul call them for you, your choice, like this
  4. After the callbacks are run, Azul tells you what's necessary next, i.e. "update the screen", "scroll nodes with ID 1, 5 and 34 by 4px", "delete / add fonts or images", etc. This has to be either handled by your renderer or you have to use webrender (and integrate WR into your renderer, I know that it's possible to integrate OpenGL into Vulkan applications, but don't ask me how).
  5. If rendering is not done by Azul, it will instead give you a CachedDisplayList (see 2.), which contains layout, rendering, etc. information about where the rectangles, fonts, etc. have to be drawn. That display list then has to be somehow handled by your custom renderer.

Currently azul depends on OpenGL (but not azul-layout or azul-core, as they are separate crates). No, there will probably not be a native Vulkan port in the near future - if webrender is ported to Vulkan or gfx-rs, then we can talk, but the current Vulkan fork of WR is still very WIP.

• Azul can run "headless", i.e. only do the construct dom->cascade->layout->display list cycle in just a few lines - just doing cascade + layout, without actually drawing anything: it outputs a CachedDisplayList, which has all the layout, style, etc. information. Technically you can use this everywhere, from embedded systems to custom renderers, since it only describes how and where the rectangles, images and fonts are supposed to show up on the screen, it doesn't define how they are drawn. That's also why azul and azul-core are two different crates: azul is meant for the desktop / mobile target and depends on webrender for rendering (which depends on OpenGL), while azul-core has close to zero dependencies and only does cascading, layout + callback handling. So if you only want the layout, you only need to depend on azul-core and azul-layout, if you also want Azul to do rendering, you need to depend on azul.

• A web target using WASM is planned, but not in the same way as QT or IMGUI do it (via rendering it to a GL texture and the using WebGL). Instead, as you might have noticed, Azul already uses DOM nodes as the main way to construct a UI. So it's just logical to use the browsers native DOM nodes and the native CSS engine for a "web compilation target". Eventually, the desktop target of Azul should have a W3C-compatible (but stripped-down) layout system, so that Azul can be sold as a better Electron replacement. That is a pretty hard task to do and will likely take a few years to implement and is not planned for a 0.1 release - however the groundwork, the core algorithms for text layout are done, it's just a matter of time.

The first goal is to get Azul running at all and to release a 0.1 version. The second step is to get the layout system to be compatible with the web (so that Azuls CSS is W3C-conform). The third step would then be to make azul-core WASM-ready and to write the necessary JS code to actually make it run on the web, but not using WebGL as a target, but the regular browser DOM. The fourth step is to document how to integrate Azul with Vulkan applications (for using it in games / interactive applications).

All of this will likely take years though, so don't hold your breath.

[nico-abram]

Thank you for the detailed response!
That addresses all my questions

[fschutt]

@nico-abram Just an update, but there is now a headless example that shows you how to use azul without webrender (to use just the layout solver, for a custom renderer - for example to export layouts to PDF or SVG). The API isn't great, but you can use it by just depending on azul-core instead of having to depend on azul, i.e. better build times because of reduced dependencies.