class SetHitRegions

Sets the interactive areas for a Transform. By default, Content is not interactive; hit

regions must be placed for a user to interact with the Content in a View. Because hit

regions are described in the Flatland protocol, a Flatland instance can synchronize Content

and hit regions.

Each hit region is placed in the coordinate space of the owning Transform, and may or may

not interact with different types of hit testing, depending on its [`HitTestInteraction`]

type. When there are multiple hit regions that intersect with a hit test, the precedence

rules given below dictate which hit region has interacted with the hit test. Only Transforms

that transitively connect to the root Transform have their hit regions interact with a hit

test.

Calling this function replaces any previous values set on this Transform. To reset a

Transform to "no hit testing": send an empty vector with [`SetHitRegions`].

Note that root transforms get a default hit region installed by Flatland. For more details,

see the [`SetRootTransform`] documentation.

Precedence rules

Within a Transform, if multiple hit regions overlap, the hit test examines each

intersecting hit region for a possible interaction. Thus, for a regular hit test R and an

accessibility hit test A, where R and A both intersect two hit regions D ([`DEFAULT`]) and

S ([`SEMANTICALLY_INVISIBLE`]) on the same Transform, (1) R interacts with both D and S,

and (2) A only interacts with D. Generally, hit regions that overlap in a single Transform

can cause confusing behavior.

Within a View, for a given hit test, the front-most Transform's hit regions take

precedence over those behind. This follows the expected reverse "render order" of

Transforms (described in [`CreateTransform`]), where a user expects to interact with

Content that is visible, or front-most.

Across Flatland instances, for a given hit test, the front-most instance's front-most

Transform's hit regions take precedence over those behind. This follows the expected

reverse "render order" of views, where a user expects to interact with the View that is

visible, or front-most. For example, if a child View owns Content that is rendered over

the parent View, the user expects to interact with the child's Content.