This property would be false if the GuiObject or any of its ancestors are not visible, if it is fully obstructed, or if it is completely hidden by ClipsDescendants.
Some use cases:
Turning off an animation when something is hidden.
Only refreshing developer console logs when they are shown, and only updating real-time graphs that are in-frame.
Only creating a list of shop items once its container is visible, and only generating a shop item’s details when it scrolls in-frame.
Writing future-proof code, just in case visibility behaviors are modified or added.
I’m pretty sure most of this already gets calculated in the C++, it would be great to have it exposed as a readonly property. This would help us create powerful, lightweight UI’s.
In Color+ and TextPlus, I have a special set of code that would do what this code does because I don’t rely on the mouse for anything in those plugins. Just another use case if needed, I would definitely like this feature.
For the name, AbsoluteVisible would work for me to go with AbsoluteSize and AbsolutePosition since they are read-only also.
Why does it need to be consistent? It’s not related to the other two. AbsoluteSize and AbsolutePosition return the size and position respectively of GUI elements in respect to the GUI render canvas. This property you’re suggesting just communicates whether an element is displayed on the screen currently. Under no circumstance should an API member be named something obscure and confusing to be consistent with other members that it is only loosely related to. API members are named to give a general idea of what they do, and giving them names that don’t accomplish this is bad design.
The API definitely needs to be consistent. Whether “AbsoluteVisible” is consistent with the rest of the API is up for debate, however.
It is related to the other two, in that its value depends on GuiObject.Property and GuiObject.Parent.AbsoluteProperty. Using “Displayed” would seem to detach it from “Visible”, which it is what it’s mainly dependent on. We shouldn’t start putting “Is” in front of every boolean property, otherwise we’d need to change Anchored to IsAnchored, and Locked to IsLocked.
“IsDisplayed”, basically breaks down to “Visible”, which is already being used.
Also, classes often have their members sorted and displayed alphabetically, and I think AbsoluteVisible would look nice next to AbsoluteSize and AbsolutePosition.
Maybe it should be a member of GuiBase2d instead? not really sure how that’s set up.
“AbsoluteVisible” is affected by more than just the Visible property of its ancestors. You mentioned in the OP that ClipDescendants would affect it as well. If ClipDescendants affects it, this property now communicates whether it’s displayed on the screen at the moment or not – not just whether all of the ancestors’ visible properties are true or not. AbsoluteVisible improperly communicates what the property does since it’s not solely dependent on GuiObject.Property like AbsolutePosition/Size.
.
You’re right – The “Is” prefix isn’t used in the ROBLOX API. IsDisplayed should be Displayed to be consistent with the ROBLOX API. As mentioned previously, this isn’t a determinate of only ancestors’ visible properties and instead communicates whether it’s being displayed on the screen, so Displayed is much more appropriate than AbsoluteVisible when it’s neither similar to either of the other two Absolute properties nor is it a one-to-one communicator of the Visible property.
No, it’s not. AbsoluteVisible is already loosely associated with the other two to start with, and also including ClipDescendants completely removes any association it had with the other two. AbsoluteSize and AbsolutePosition are one-to-one relations to a single property. As you mentioned previously, GuiObject.AbsoluteProperty is directly related to GuiObject.Property. GuiObject.AbsoluteVisible is related not only to GuiObject.Visible, but also to GuiObject.ClipDescendants, and the name does not properly communicate this.
I visualize ClipsDescendants making chunks of its children not visible. Hmm, using AbsoluteVisible, when a child could stick out the side and be visible does seem odd. I’m convinced, AbsoluteVisible makes sense for a property, but not one with this behavior. It might be more useful to be able to potentially include other cases, like when a fully opaque frame is in front of it, which isn’t directly related to the object’s ancestry at all.
Maybe something along the lines of “VisibleOnScreen”?
I’d really love something like this too:
I have hover text pop up for buttons to provide extra information, and while I watch the button’s Visible property to hide the text, I don’t know to hide the text if one of the button’s ancestors changes transparency
(This could also be solved if Roblox fired MouseLeave when VisibleOnScreen becomes false-which makes sense intuitively-but I think this VisibleOnScreen is a much more powerful property for us developers to be able to access)
I often wonder why this isn’t implemented yet. This would be a game changer for GUI performance.
Modern day use-case: Having hundreds of items in a ScrollingFrame. Why run animations and calculations for everyitem if only a dozen are visible on the screen? This becomes impossible once the number of items goes into the thousands. Sacrificing creativity at the cost of performance.
Isn’t this already being calculated internally for UIListLayouts, etc? Why not make that information available in real time to developers?
I think it’s something to do with this information being calculated by the GPU and it being expensive to reflect this up to lua (even lazily?), but idrk? I think I really want to learn more about this though
I needed this recently when making a UI fading script. For each object, I checked if it was visible or not to determine whether to use a tween on that object or not. The problem with that is that any descendants of an object that has Visible to false will still have a tween, even though they aren’t actually visible. Adding this would mean that I could check VisibleOnScreen instead of Visible and save lots of extra useless tweens.