(question) wgpui AND walker or galileo (both wgpu)

[sectore]

Idea: Running walkers OR galileo (both are world/tile map renderers targeting wgpu) and gpui (via WGPUI) together.

Maybe very similar to what Pulsar-Native has already done and described in BEVY_RENDER_THREAD.md.

However, I'm still not sure if WGPUI is the right place. Maybe gpu_canvas or anything else might be worth to start with.

Any hints or a first direction would be much appreciated!

[tristanpoland]

@sectore Both look like interesting projects. What would the goal of adding these be? Are they particularly useful for rendering something other than map data?

[tristanpoland]

@sectore rereading I think I get it! Do you want to make an app that does something like what Pulsar does with bevy, but for a maps app?

[sectore]

Yeah. Goal is to build a desktop app to render a map and having a gpui based UI on top on it. Something like I have already done using rerun here, but with nicer UI and better UX etc.

I've already started to build such thing with egui, which works fine with walkers or galileo. However, I think I can build a better UI with gpui. Also I like the structure of an gpui app comparing to egui.

[tristanpoland]

@sectore During early experimentation, we attempted to render the bevy scene directly inside GPUI. In practice, this proved problematic for several reasons:

GPUI is not designed as an immediate-mode renderer, which made tight render-loop integration difficult.
Performance and reliability issues appeared across all platforms.
On Windows and Linux specifically, there were severe issues from overloading the event bus with refresh requests.
As a result, Pulsar deliberately moved to a compositing model:

The engine renders one or more viewports into a custom framebuffer.
GPUI is rendered separately with a “hole” where the viewport should appear.
The final frame composites GPUI atop the engine-rendered content.
Image example:

This method involves modifying GPUI so it supports rendering to a buffer instead of its own internal window, and take external inputs instead of the ones from its own window system.

After this it's as simple as building a basic compositor shader to do the process in the diagram above.

This, and conversation to wgpu is what we are working on with wgpui ( most changes are not yet published)

[tristanpoland]

@sectore To clarify further the viewport docs refer to rendering bevy to a buffer (we still do) but instead of injecting it into GPUI through gpu-canvas, we now instead render it "behind" GPUI by drawing partly transparent GPUI buffer over top.

[tristanpoland]

@sectore this will be vastly improved shortly https://github.com/Far-Beyond-Pulsar/Pulsar-Native/blob/7e05298fdf404a7d35e58c2adce2b568417e63f3/crates/engine/src/window/mod.rs