gpui: Fix broken rendering with nested opacity

[unixzii]

Rendering breaks when both an element and its parent have opacity set. The following code reproduces the issue:

struct Repro;

impl Render for Repro {
    fn render(&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
        fn make_box(bg: impl Into<Fill>) -> impl IntoElement {
            div().size_8().bg(bg).hover(|style| style.opacity(0.5))
        }

        div()
            .flex()
            .items_center()
            .justify_center()
            .size(px(500.0))
            .hover(|style| style.opacity(0.5))
            .child(make_box(gpui::red()))
            .child(make_box(gpui::green()))
            .child(make_box(gpui::blue()))
    }
}

Before (broken behavior):

Screen.Recording.2025-07-31.at.22.46.30.mov

The child element resets its parent and siblings' opacity, which is an unexpected behavior.

After (fixed behavior):

Screen.Recording.2025-07-31.at.22.50.16.mov

Release Notes:

• Fixed an issue where nested opacity is rendered incorrectly.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @unixzii on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[unixzii]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[MrSubidubi]

Hey, sorry for the slow reply, thank you for both finding and fixing this issue!

I think we can slightly improve this though: We don't need to change the element_opacity from an Option to a Vec, as we can just keep the old element_opacity value around within with_element_opacity and then reassign it after f was called instead of always resetting it to None. What do you think?

Also, I think it would be nice if we could test this somehow or at least extend one example to cover this behavior, if you see fit somewhere for that.

[unixzii]

Hi @MrSubidubi, thank you for the advice. Nice observation!

I'll keep the Option type and manage the opacity state properly in with_element_opacity. And I updated the opacity example to demonstrate the use case this PR fixes.

Before the fix:

Screen.Recording.2025-09-02.at.21.01.45.mov

After the fix:

Screen.Recording.2025-09-02.at.21.05.19.mov

Btw, there are also some other rendering properties that can be maintained without using Vec stack. Do you think we should remove them as well?

[MrSubidubi]

Looks better, thank you! I'll leave the final verdict here to @\mikayla-maki once she is back from vacation, and then we should be good to go!

One last thing - we could probably even change the self.element_opacity to a f32 only and just assign it 1.0 by default - that's basically what the unwrap_or call already does currently for us, only now in two places. But I don't think this is too important, happy to hear your opinion on it.

---

Also, I do think we would be interested, but this is probably better for a separate PR so we can also review this and decide upon separately. Yet, sounds good and reasonable to me, if you agree there, feel free to take a look!

[unixzii]

One last thing - we could probably even change the self.element_opacity to a f32 only and just assign it 1.0 by default - that's basically what the unwrap_or call already does currently for us, only now in two places. But I don't think this is too important, happy to hear your opinion on it.

That makes sense -- I'll change it, since I think it should help with performance.

Also, I do think we would be interested, but this is probably better for a separate PR so we can also review this and decide upon separately. Yet, sounds good and reasonable to me, if you agree there, feel free to take a look!

Yeah, maybe I can open another PR for those later.

[MrSubidubi]

Given that this has been sitting around for quite some time without any objections, I am gonna go ahead and merge this. Thank you for this fix and being that receptive to feedback! Much appreciated and a sincere sorry this has been sitting here for so long.

Also, congratulations to your first contribution! 🎉