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

Radial Gradient #28

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Radial Gradient #28

wants to merge 4 commits into from

Conversation

egonelbre
Copy link
Contributor

Implementation of RadialGradient, I'm unsure whether we wanted to merge this or not. But I updated it, such that people can try and experiment if they want to.

It's hard to follow large number of elements that need to be in the
correct order. Use material types as indices, which should make the
implementation clearer.

Signed-off-by: Egon Elbre <[email protected]>
Copy link
Contributor

@eliasnaur eliasnaur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, I'd like to hold off features not implemented in the compute renderer.

FWIW, the rendering of materials have been split out to a separate (fixed function) pass, which may be easier to modify for gradients. See renderMaterials.

@egonelbre
Copy link
Contributor Author

@eliasnaur I took a look at the renderMaterials, but doesn't this imply it'll create a texture for every gradient?

For example in https://github.com/egonelbre/expgio/blob/master/box-shadows/surface.go, it currently creates 8*3 = 24 gradients for a single surface. Those gradients would add up really fast for anything more complex. While I understand that a specialized "round-rect-shadow" would reduce it to a single additional tex per atlas, it could still be problematic in other scenarios.

@eliasnaur
Copy link
Contributor

@eliasnaur I took a look at the renderMaterials, but doesn't this imply it'll create a texture for every gradient?

A atlas reservation per gradient, but otherwise yes. I just pushed gioui.org/commit/3a3ec711d388a7 that caches materials off a (transformation, image handle) key. If two gradients are equal, they can re-use that space.

For example in https://github.com/egonelbre/expgio/blob/master/box-shadows/surface.go, it currently creates 8*3 = 24 gradients for a single surface. Those gradients would add up really fast for anything more complex. While I understand that a specialized "round-rect-shadow" would reduce it to a single additional tex per atlas, it could still be problematic in other scenarios.

Indeed your example is expensive in texture memory, but I'll gladly settle for "it works, wasting memory" than not implemented at all.

Alternatives include: adding gradient support to piet-gpu (Raph is open to other material types); adding a "drop-shadow" material to Gio or effect to piet-gpu (we're likely going to need that eventually). Both options seem like more work, and I don't see myself working on either in the near future.

@whereswaldon whereswaldon force-pushed the main branch 9 times, most recently from 3d36537 to 74ccc9c Compare June 27, 2024 14:39
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.

2 participants