Re-implement PaintCallbacks With Support for WGPU - #1684
Conversation
3f5e4aa to
c83c281
Compare
This makes breaking changes to the PaintCallback system, but makes it flexible enough to support both the WGPU and glow backends with custom rendering. Also adds a WGPU equivalent to the glow demo for custom painting.
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
84f968c to
f79b273
Compare
f79b273 to
7aee50b
Compare
|
Great review points, I addressed them all, I believe, and CI is happy, too! |
| painter | ||
| }; | ||
|
|
||
| let render_state = painter.get_render_state().expect("Uninitialized"); |
There was a problem hiding this comment.
This always panics on Android, so this breaks the support added in #1634.
There was a problem hiding this comment.
Well that's not cool! I don't have an Android to test on unfortunately.
Still, I did try to build it for Android real quick. A quick look over and, it appears that there is multiple things breaking the ability to build eframe for android right now, that isn't related to this PR. It looks like #1634 might not have actually gotten eframe building for Android, just egui_wgpu and egui_winit.
Some things I noticed need to be fixed for eframe will build for Android:
- The inclusion of the
arboardcrate for clipboard support needs to be made optional, because it doesn't build for android. - Same fix for the
glutindependency - It appears that the
winit::event::Event::Pausedevent doesn't exist, but it's used in the android event loop code.
For what I can tell, it looks like the eframe crate hasn't ever actually worked for Android yet, but it might not be a big deal to make work. I'm not sure if I'll be able to get the time to try to get it working yet, though.
There was a problem hiding this comment.
I have things half working on Android. Buttons show up, but no text.
Paused is called Suspended now. glutin master works, and there's an open PR to fix arboard.
It would probably be a good idea to add cargo check --target aarch64-linux-android to CI to avoid build errors at least.
There was a problem hiding this comment.
Cool! We shouldn't actually need glutin anyway if we are using the WGPU backend. I'm not sure why text wouldn't be working.
There was a problem hiding this comment.
Nice to hear some progress on this! Feel free to open a PR to add cargo check --target aarch64-linux-android to CI, and any other needed changes
|
This also apparently broke DX12's CPU renderer as |
|
That's another platform I can't test for unfortunately. 😕 I just have a Linux machine with Vulkan and OpenGL. |
This makes breaking changes to the PaintCallback system, but makes it
flexible enough to support both the WGPU and glow backends with custom
rendering.
Also adds a WGPU equivalent to the glow demo for custom painting.
Closes #1661.
This includes breaking changes to the way that
PaintCallbacksare used. Instead of the paint callback downcasting acontextargument to a specific backend context, the backend will downcast thecallbackto a backend-specific callback function.This is required to allow greater divergence from the backend APIs. For example, the WGPU backend needs two callbacks with different arguments for each, and it also has arguments that are not
'static, meaning that having adyn Anyargument doesn't work.