Canvas Renderer Cull API

Hi,

I have a question about “Canvas Renderer Cull API”

This is a very nice feature.
Will you implement an Event to fire when an element become cull or not ?

This could be usefull to do infinite scroll view for instance, and set new visible element to the proper data they have to show.

Thanks

This is a good feature request. It will only work for things that go VIA the cull API. I’ll add it to the TODO.

I have added this callback. Any maskable graphic can implement it like so:

public class CallbackTest : MonoBehaviour
{

    void Start()
    {
        var image = GetComponent<Image>();
        image.onCullStateChanged.AddListener (OnCullChanged);
    }
    void OnCullChanged(bool newState)
    {
        Debug.Log("I am now in state: " + newState);
    }
}

Just in case, It will called even if canvasRenderer.cull is set from code, right?

2 questions more:

  1. Are you planning to add .cull to CanvasGroup?
    Seems to be efficient way to hide element instead of current clumsy Canvas + CanvasGroup.alpha = 0 or heavy enabling/disabling GO.

  2. Are elements out of screen culled?

Currently it’s on MaskableGraphic so that means that Image and text get it. If we add it to the canvasRenderer then the calls can not be set up to be persistent (we can’t persist a c# function from the native side).

It’s a property of canvas renderer, It doesn’t make sense currently for the group.

If you add a 2D rect mask to the canvas then they will be culled.

Can’t it be made like IPointerClickHandler etc so we can implement it for any canvasRenderer and event for MaskableGraphic?

It makes sense as a lightweight way to disable some part of UI. Imagine that I want to hide a chat with lots of text - disabling/enabling GO leads to noticeable hiccup so currently only way is to add Canvas + CanvasGroup to that “chat” and set alpha to 0.

It’s OK with performance? I mean whole screen in mask looks suspicious :slight_smile:

Not really ontopic as far as UI goes, but are you guys planning on registering callbacks like this for more of the already existing callbacks that are currently cluttering the MonoBehaviour api (under the ‘Messages’ section)? I understand that you want to keep backwards compatibility but I think some of these messages would have a better fit with this callback pattern (Animator callbacks, Application focus, quit etc, transform changes)