Add transparent MOAP background and click pass-through support - #6015
Add transparent MOAP background and click pass-through support#6015shadoskill wants to merge 5 commits into
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
There was a problem hiding this comment.
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 | ||
|
|
|
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
left a comment
There was a problem hiding this comment.
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.
| // embedded background color to match the floater background | ||
| // and set it to white | ||
| settings.background_color = 0xffffffff; // white | ||
| settings.background_color = 0x00000000; // transparent |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
… face. Changed transparency to support future server message TODO add in "overwrite" in llmediaentry when server adds support for new message.
|
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. |
| sd[PERMS_CONTROL_KEY] = mPermsControl; | ||
|
|
||
| // "display" fields | ||
| sd[TRANSPARENT_BACKGROUND_KEY] = mTransparentBackground; |
There was a problem hiding this comment.
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.
|
I tested MOAP, and it is broken. (That is the determination made.) It slows the game down, but it is the ability to click on something to restore all or parts of commits (with payload) that we want to look at. They get deleted when spawned. It is a bug that needs fixing. MOAP is highly insecure, as in $US Dollars. Sometimes everybody waits for a fix. |
|
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.
|
|
@Dzonatas that isn't relevant for current PR, if you have performance problems with moap, I suggest reporting them with specific scenarios and examples. |

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:
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