Add transparent MOAP background and click pass-through support by shadoskill · Pull Request #6015 · secondlife/viewer

shadoskill · 2026-07-17T00:32:09Z

Description

This allows for media-on-a-prim to have its background fully transparent if the website sets it via CSS.
This also allow click pass-through to in world objects if clicking a fully transparent area on the moap.

Checklist

Please ensure the following before requesting review:

I have provided a clear title and detailed description for this pull request.
If useful, I have included media such as screenshots and video to show off my changes.
The PR is linked to a relevant issue with sufficient context.
I have tested the changes locally and verified they work as intended.
All new and existing tests pass.
Code follows the project's style guidelines.
Documentation has been updated if needed.
Any dependent changes have been merged and published in downstream modules
I have reviewed the contributing guidelines.

Additional Notes

Video of the feature and link to basic test page used in the video.

https://fullarray-dev.emptylist.co/moap_test.html

PowerToys_QwooSaIhZr.mp4

github-actions · 2026-07-17T00:32:20Z

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

shadoskill · 2026-07-17T00:35:26Z

I have read the CLA Document and I hereby sign the CLA

Copilot

Pull request overview

Enables alpha-aware rendering for Media-On-A-Prim (MOAP) so web content can display with a truly transparent background, and updates picking/click handling so mouse events can pass through fully transparent media pixels to in-world objects behind.

Changes:

Treat RGBA media textures as alpha in the render pipeline so transparency is respected.
Add per-pixel transparency sampling for media textures (mask/pick support) via LLViewerMediaImpl::isTransparentAt().
Update pie tool click/hover handling to defer to the visible pick when the media pixel is fully transparent; update CEF plugin defaults for RGBA/transparent background.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
indra/newview/pipeline.cpp	Routes RGBA textures (including media) into alpha rendering when appropriate.
indra/newview/llviewertexture.h	Declares media-texture pick mask override to support transparency-aware picking.
indra/newview/llviewertexture.cpp	Implements media-texture `getMask()` by sampling the live media buffer.
indra/newview/llviewermedia.h	Adds `isTransparentAt()` API for per-pixel alpha testing at UV coords.
indra/newview/llviewermedia.cpp	Implements per-pixel alpha sampling and clears media placeholder with transparent alpha.
indra/newview/lltoolpie.cpp	Adds click/hover pass-through logic when the hit media pixel is fully transparent.
indra/media_plugins/cef/media_plugin_cef.cpp	Switches embedded CEF background/format to preserve alpha (RGBA/transparent).
indra/llrender/llgltexture.h	Makes `getMask()` virtual to allow media textures to override pick masking.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

                // SL-15560: Product team overruled my change to set the default
                // embedded background color to match the floater background
                // and set it to white
-                settings.background_color = 0xffffffff; // white
+                settings.background_color = 0x00000000; // transparent



akleshchev · 2026-07-18T07:18:49Z

This is likely to affect existing content, may be even render some content unreadable due to matching color of the background. I wonder if we can get some form of 'respect transparent background' checkbox to work on per-face basis. It should be trivial viewer side to store the value in LLMediaEntry, but server might will need to support it.

callumlinden

As well as my comment on the background color, I would echo @akleshchev's point about existing content. We do not want to make pages unclickable because someone specified a transparent background color in older content.

callumlinden · 2026-07-20T17:36:39Z

                // embedded background color to match the floater background
                // and set it to white
-                settings.background_color = 0xffffffff; // white
+                settings.background_color = 0x00000000; // transparent


This line means the default background color will be #000000 (black) so pages that do not specify a background color will inherit a black background.

Is that what you intended?

That was not the intention no, I must have forgot to change that doing some testing.

As for existing content, I did some testing and yeah any blank page that does not have a CSS set background does show as fully transparent.

I added a toggle in media general settings to toggle it per face, and it should be ready for a future server message if I did everything correctly.
For now the checkbox is session based for testing so it wont get set back to false from the server not knowing about it.

Wonderful - thank you for your excellent contribution. We'll ask our product folk to look at it since it has some potential content impacts and once we get their blessing, we'll merge it in.

Thank you.

…hite.

… face. Changed transparency to support future server message TODO add in "overwrite" in llmediaentry when server adds support for new message.

Geenz · 2026-07-29T17:09:43Z

Popping in here - what we might want to do instead is have a meta tag in the HTML that "opts in" to this rather than a flag from the simulator. Would require a little more plumbing I think to get that meta tag out, but I think it might be worth it to go this way instead of finding a server release for a change to an already pretty packed wire protocol.

Geenz · 2026-07-29T18:00:37Z

    sd[PERMS_CONTROL_KEY] = mPermsControl;
+
+    // "display" fields
+    sd[TRANSPARENT_BACKGROUND_KEY] = mTransparentBackground;


Note for if we stick with having an entry flag for this: you will want to extend unit tests to account for this. The existing tests are failing.

…ground. Add transparent_background field to DEFAULT_MEDIA_ENTRY, EMPTY_MEDIA_ENTRY, and PARTIAL_MEDIA_ENTRY tests. Fix copy constructor missing mTransparentBackground.

DarlCat · 2026-08-03T13:40:20Z

I've found a way to avoid breaking content while not requiring Second Life-specific opt-in behavior from websites to enable transparency.

https://github.com/DarlCat/secondlife-viewer/tree/MOAP

The downside though is that it currently requires a patch to dullahan to facilitate injecting a very small piece of javascript into the webpage which means javascript must be enabled in CEF.

https://github.com/DarlCat/dullahan/tree/transparent-background

Since there is not much of any use for this transparency feature without dynamic webpages IMO; while not ideal in the slightest the tie-in isn't the worst tradeoff.

A cleaner approach without injection or a platform-specific meta tag detection would be patching CEF directly, something I'm hesitant to do. I see something that makes Second Life web content require nonstandard meta tags as equally undesirable to patching CEF. I did search around for a formal or informal standard to adopt for flagging webpages as supporting non-opaque rendering, but found none.

I know that there is currently an embedded content project underway in the dullahan repo, so it is possible there may duplicated work or different solutions to shared issues on both sides; hopefully we can share ideas with each other along the way if so.

akleshchev · 2026-08-03T16:09:05Z

@Dzonatas that isn't relevant for current PR, if you have performance problems with moap, I suggest reporting them with specific scenarios and examples.

Geenz · 2026-08-04T15:07:53Z

@DarlCat I really don't think that a bit of JS is the way to go here. A single SL specific meta tag I think is completely fine in this scenario. Either way, we need something that is SL specific that we need to account for somehwere, and I'm not fond of using a media entry flag here. We need an author-time flag that a content creator can mark pages with as "hey, do this".

I should also note that not every page needs this - so a content creator might have one set of pages that does this, and another set that does not. So doing this page by page is not a bad idea I believe. Really at the end of the day, to me the ideal setup is going to be something embedded by the author in the HTML.

DarlCat · 2026-08-04T15:28:23Z

Respectfully, isn't the background-color of the <html> element being translucent as defined by CSS an intentional-enough author signal?

I've had a potion of my career in web development and I subjectively believe that it is. However if a specific meta tag is still the lab's desired way to go with this that's the direction this PR can go.

Geenz · 2026-08-04T15:54:30Z

We would need to review existing content that makes use of MOAP to ensure that it's not suddenly going semi-transparent - which I don't think there's a 0% chance of. This is far from standard functionality for a web browser - and you encounter all sorts of weird edge cases with this sort of thing. Even if by accident (as in "eh, it doesn't do anything so no harm leaving it in"), we can't really risk breaking content with this.

shadoskill added 2 commits July 16, 2026 16:36

Add support for transparent MOAP background.

407f5a4

Add support for click pass through on fully transparent pixels.

d0db1af

github-actions Bot added the c/cpp label Jul 17, 2026

github-actions Bot added the llrender label Jul 17, 2026

akleshchev requested review from akleshchev, callumlinden and Copilot July 18, 2026 06:59

Copilot started reviewing on behalf of akleshchev July 18, 2026 07:00 View session

Copilot AI reviewed Jul 18, 2026

View reviewed changes

callumlinden reviewed Jul 20, 2026

View reviewed changes

shadoskill added 2 commits July 20, 2026 12:56

Fixed background being set to black instead of just transparent and w…

bf8b2bd

…hite.

Added a checkbox to media general settings to toggle transparency per…

19dcd0a

… face. Changed transparency to support future server message TODO add in "overwrite" in llmediaentry when server adds support for new message.

github-actions Bot added llprimitive llplugin labels Jul 20, 2026

akleshchev linked an issue Jul 20, 2026 that may be closed by this pull request

Click pass-through through transparent media #6027

Open

akleshchev mentioned this pull request Jul 20, 2026

Click pass-through through transparent media #6027

Open

akleshchev requested review from Steeltoe-Linden and kylelinden July 22, 2026 16:19

Geenz self-requested a review July 29, 2026 17:09

Geenz reviewed Jul 29, 2026

View reviewed changes

Fix LLMediaEntry unit tests and copy constructor for transparent_back…

f96fc21

…ground. Add transparent_background field to DEFAULT_MEDIA_ENTRY, EMPTY_MEDIA_ENTRY, and PARTIAL_MEDIA_ENTRY tests. Fix copy constructor missing mTransparentBackground.

This comment was marked as off-topic.

Sign in to view

Uh oh!

Conversation

shadoskill commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Additional Notes

Uh oh!

github-actions Bot commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shadoskill commented Jul 17, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

akleshchev commented Jul 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

callumlinden left a comment

Choose a reason for hiding this comment

Uh oh!

callumlinden Jul 20, 2026

Choose a reason for hiding this comment

Uh oh!

shadoskill Jul 20, 2026

Choose a reason for hiding this comment

Uh oh!

callumlinden Jul 20, 2026

Choose a reason for hiding this comment

Uh oh!

Geenz commented Jul 29, 2026

Uh oh!

Geenz Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

This comment was marked as off-topic.

DarlCat commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

akleshchev commented Aug 3, 2026

Uh oh!

This comment was marked as off-topic.

Geenz commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DarlCat commented Aug 4, 2026

Uh oh!

Geenz commented Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

shadoskill commented Jul 17, 2026 •

edited

Loading

github-actions Bot commented Jul 17, 2026 •

edited

Loading

akleshchev commented Jul 18, 2026 •

edited

Loading

DarlCat commented Aug 3, 2026 •

edited

Loading

Geenz commented Aug 4, 2026 •

edited

Loading