pixels + egui drawing area

[vilhub]

Hey all,

First of all thanks for the great library! I have a beginner question related to the example with egui : https://github.com/parasyte/pixels/tree/main/examples/minimal-egui

If you run the example, you can see the square bouncing around and going under the top panel of the UI. My question is essentially, how would I proceed to have the rectangle only bounce around the visible area?

As I understand it the SurfaceTexture has to be initialized from a Window and the UI is drawn on top. Therefore pixels and egui independently draw on the same window.

One possible solution would obviously be to hardcode a margin at the top and adapt the square bouncing logic to bounce at the margin. However, if the UI changes, the logic has to be adapted again. Would you see a cleaner solution? I was thinking of ideally having an egui frame which could be drawn into by pixels. However, I'm not sure if that's possible since pixels draws directly into a window.

Any conceptual perspective is appreciated. Thanks!

[parasyte]

Hey! I have been wanting to update the egui example to address this. Right now I'm blocked waiting on egui-wgpu not supporting wgpu textures in 0.18. (It's available in the main branch, but currently unreleased.) You can still use the older egui_wgpu_backend like the example, though.

You can create an egui image with egui_texture_from_wgpu_texture(), and the wgpu texture can be retrieved with Pixels::texture(). You'll have to create a texture view for it. Once you have the egui TextureId, just call ui.image() and it will draw just like any egui widget.

You don't need to call ScalingRenderer::render if you are doing this. And because the scaling renderer is not used, you won't get any of the scaling behavior like centering with a border. If you want to scale the image, you will do that with the size argument to ui.image().

---

This is pretty hard to follow, sorry about that. I could update the example without replacing egui_wgpu_backend if that would help. A similar question was asked in #268, and my response there was also similar. :)

[vilhub]

Hi @parasyte ,

Thanks a lot for the detailed answer. I was able to draw into an egui image with the steps you mentioned. For now the window size is still coupled with the drawing canvas size in this commit so the square goes out of bounds at the bottom and right but the general concept of it seems to work, see this commit.

As I'm new to the wgpu, egui and pixels world, the modifications above probably have sub-optimal structure as I'm still figuring out how it all works but at least it's a start.

Thanks again!

[parasyte]

That looks good, but you probably don’t want to scale the size given to egui. It uses “virtual pixel coordinates” already.

I also forgot about this old branch. But it shows a way to automatically resize the window to match the menu bar height. main...egui-menubar-size-v2

[vilhub]

Great, I adapted the example to take into account the menubar height like in your branch, see this commit.

Concerning the size given to egui, if I don't scale it, the drawn pixels image would appear 2x oversized if run in an environment with 2x scaling because the width and height argument (1280 x 960) to the Framework constructor are 2x the virtual sizes (640 x 480). In the commit I instead now take the width and height from the given constants in the main. It seems to work but let me know if there's a more proper way of doing this.

[parasyte]

Concerning the size given to egui, if I don't scale it, the drawn pixels image would appear 2x oversized if run in an environment with 2x scaling

Yes, that’s what I was trying to describe above. You can fix it by removing the scale factor adjustment on this line: 68672b7#diff-9f6de21a8983bad043e8bad770e53c644b98ab334c39a0fd76412b702cc5ffafR45

[ParthPant]

An example would be very helpful!
I am working on implementing a Chess Game that requires drawing the chess board and sensing drag-and-drop events. I was hoping I could integrate eframe and Pixels. Would make my job much easier by not having to write a framework that handles winit and web separately. Right now I have used the tiny_skia example but tighter integration with egui would be much better.

[parasyte]

@ParthPant you can combine our egui and web examples to do that. While I have used eframe in a project, I don't think its model can be compatible if we fix #238, since both pixels and eframe will need ownership over the window.

Composition of generic ownership is really hard. You can see how the game-loop crate tries to do it with feature flags right now, and in tuzz/game-loop#10 there is some discussion about how it might be done better.

Anyway, my current recommendation is to use the lower-level crates instead, since they can compose nicely. It's more work for you to manage the "framework" part but it also gives you a lot more freedom and flexibility that a one-size-fits-all solution cannot offer. And honestly it isn't much more work.

[ParthPant]

Hi @parasyte. Thanks for the speedy response. You made a fair point. I came accross egui_winit_platform. Seems to make egui and winit integration a little easier.

[parasyte]

Yeah, that's the older crate that was mostly superseded by egui-winit. (We used to use it: #217.) I'm kind of surprised that it's still getting updates. 😅 If it works for you, it works!!

[anacrolix]

I've come across this problem also. I've tried altering the ScalingRenderer to move the non-egui output (i.e. just where the pixels in Pixels get drawn) to below the bottom of the egui menu. You can get the bottom of the egui menu by passing it out from the egui prepare method. I then pass this in in to the ScalingRenderer. I'm able to move the pixels down easily enough by altering the ty variable in the transform. However I can't get it to scale the output correctly. I end up losing the same number of pixels from the bottom than I transformed, even though I tried to alter the scaling to match.

Here's a super minimal change to demonstrate: main...anacrolix:pixels:scale-below-egui-menu. It would be amazing if someone could point out what I need to get it to fit correctly, I might be able to then generalize it to the Pixels API properly and make a PR (basically to have Pixels write its pixel frame to a specific region of the surface).

[dbalsom]

You can see my answer here #290

The code for the scaling with top margin is here
https://github.com/dbalsom/martypc/blob/387dd036648e1516bdc62e549675f4393e49a550/lib/frontend/marty_scaler_wgpu/src/lib.rs#L1044

the target rect and margin allows for aspect ratio correction as well as dodging the top menu. I think an actual API change should take a margin rect so that configurable margins could be calculated on all sides.

[anacrolix]

Thanks! That's given me what I need to solve the issue: anacrolix@9f5b344.

Re the margins, that's what I meant by

have Pixels write its pixel frame to a specific region of the surface

The target in Pixels currently being (0, 0, screen_width, screen_height), but allow to pass something else. In my demo, and your linked code above, we have specified only y (margin_top), calculated the screen_height from that, and left everything else alone.