Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Shape::Callback to do custom rendering inside of an egui UI #1351

Merged
merged 7 commits into from Mar 14, 2022

Conversation

emilk
Copy link
Owner

@emilk emilk commented Mar 10, 2022

This adds a new shape Shape::Callback which can be used to inline custom rendering code inside an egui UI. The callback will be given the underlying rendering context, and will therefore be integration specific. When using eframe, it will be glow::Context (unless one opts in to the glium or WebGL backends).

This means you can paint anything anywhere, including behind or on top of other egui windows and with transparency. Previously this was only possible by first rendering to a texture and then displaying that texture using egui::TextureId.

The design is very similar to Dear ImGui's AddCallback/UserCallback.

Mar-10-2022 12-50-57

Closes #1198

Unresolved issues

One unresolved issue is where to free any resources (shaders, buffer, textures, …) allocated by the custom painting callback. Perhaps we could pass a Rc<Cell<glow::Context>> and let the user clone it and destroy the resources on Drop?

@coderedart
Copy link
Contributor

glow::Context doesn't need to be mutable. so, a simple Rc<glow::Context> should be good. window must be alive for Rc<glow::Context> to work in their User struct Drop impl (otherwise, segfaults). .

one question i have is whether the user will be able to access the textures loaded into egui already? I would assume they don't want to duplicate textures in their app used both by egui::Image as well as their own custom rendering code, so reusing the textures from egui's tex manager would be cool.

@emilk
Copy link
Owner Author

emilk commented Mar 10, 2022

one question i have is whether the user will be able to access the textures loaded into egui already? I would assume they don't want to duplicate textures in their app used both by egui::Image as well as their own custom rendering code, so reusing the textures from egui's tex manager would be cool.

Great question!

My initial thinking was that a user would either want to either manage their textures manually OR ask egui to do so, but not both. But I guess we could pass the full egui_glow::Painter along with glow::Context so the users could ask for any textures they desire.

@KentaTheBugMaker
Copy link
Contributor

KentaTheBugMaker commented Mar 10, 2022

if we able to redirecting to Texture would save energy.

in this case pass Painter to user would better.

@emilk emilk force-pushed the pain-shape-callback branch 2 times, most recently from 37227eb to a913449 Compare March 11, 2022 14:05
@emilk
Copy link
Owner Author

emilk commented Mar 11, 2022

There - now the callback code has access to egui_glow::Painter which contains the glow::Context and all textures.

@emilk emilk force-pushed the pain-shape-callback branch 2 times, most recently from 39e2c7d to 8c2ec55 Compare March 13, 2022 21:50
@emilk emilk marked this pull request as ready for review March 14, 2022 09:01
@emilk
Copy link
Owner Author

emilk commented Mar 14, 2022

I think this is a decent start.

Future work: Make glow a first-class part of the epi/eframe interface so that users can run glow-related setup- and teardown code. Coming in:

@emilk emilk merged commit 6aee499 into master Mar 14, 2022
@emilk emilk deleted the pain-shape-callback branch March 14, 2022 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose glow::Context via epi::Frame
3 participants