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

Screen-space pixel bounds? #34

Open
kaphula opened this issue Apr 5, 2024 · 2 comments
Open

Screen-space pixel bounds? #34

kaphula opened this issue Apr 5, 2024 · 2 comments
Labels
wontfix This will not be worked on

Comments

@kaphula
Copy link

kaphula commented Apr 5, 2024

Hi,

Is it possible to define rectangular bounds for a section in screen space pixels? There is a function called .with_bounds() but in my understanding it can be only used to define the bounds from the section's origin up to the direction of layout settings.

Let us say I want to have a dialog box somewhere on my screen and render text inside that dialog box. If I move the text with motion inside the dialog box so that it reaches the edge of the dialog box and goes beyond it, the text should be clipped to the borders of the dialog box. There is no way to achieve this with .with_bounds() for every possible direction inside the dialog box?

Since a brush draws all of its sections at once, I don't see how I could make use of render_pass.set_scissor_rect for individual sections of the brush without creating a custom brush for every individual area on the screen I want to clip, which sounds pretty bad.

I use render_pass.set_scissor_rect for my other own UI elements to get this clipping effect. I separate draw calls that use clipping and draw calls that don't. Draw calls that use clipping are sorted by the clipping area, and each draw call set first calls render_pass.set_scissor_rect and then "draws" its draw calls.

Any thoughts on this?

@Blatko1
Copy link
Owner

Blatko1 commented Apr 8, 2024

I have tried making it so multiple different text sections can be rendered through different draw calls in the same render pass, but sadly with no success (look #17). Because of how the dependency crate glyph_brush works, all text is meant to be rendered in one call each frame. Consequently, this crate is heavily restricted. You can try the glyphon crate which is probably more flexible than this crate.

@kaphula
Copy link
Author

kaphula commented Apr 10, 2024

That is unfortunate. I will look around the implementations at some point. I guess the only way to go then is to implement some kind of boundary clipping system on glyph_brush side first, that is, if they are even willing to accept such features as PRs.

@Blatko1 Blatko1 added the wontfix This will not be worked on label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants