1309329 - Include cursor information in layer tree

Status: NEW

(Core :: Graphics: Layers, task, P4)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Perhaps I'm unusual, but one of the main ways I notice jank is that the cursor fails to change when I move it over text or clickable content. I wonder if we could change the cursor asynchronously? Could we include, in each layer, a list of rectangles and the cursor that should be used when the mouse is inside that rectangle? There are probably some cases where this wouldn't work, but hopefully we could make it happen in the common case.

kats, Olli, do you think this might be feasible?

Comment 1

[Kartikaya Gupta (email:[e-mail])]

The rectangles sound fairly similar conceptually to event regions, which we already pass over to the compositor. They also introduced a pretty significant overhead with a bunch of talos regressions, so I'm reluctant to take another hit like that for something like this.

Also AFAIK we usually need to call system APIs to change the cursor and that needs to be done from the main thread. I might be mistaken on that.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> The rectangles sound fairly similar conceptually to event regions, which we
> already pass over to the compositor. They also introduced a pretty
> significant overhead with a bunch of talos regressions, so I'm reluctant to
> take another hit like that for something like this.

I wonder if we could only send this information when the content process is already hung for a little bit. The threshold would have to be pretty short in order for it to be useful. Maybe 20ms or so.

What regions do event regions cover?

> Also AFAIK we usually need to call system APIs to change the cursor and that
> needs to be done from the main thread. I might be mistaken on that.

That's fine. The main thread of the UI process is unlikely to be blocked, so we could just post a runnable to it asking to change the cursor.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(In reply to Bill McCloskey (:billm) from comment #2)
> I wonder if we could only send this information when the content process is
> already hung for a little bit. The threshold would have to be pretty short
> in order for it to be useful. Maybe 20ms or so.

Would this again be a case of interrupting JS to go do a display list build and generate this information? Because I wouldn't want to compute the information on every paint, as it will not be worth it.

> What regions do event regions cover?

The data structure is at [1]. It's used by APZ to hit-test incoming input events. So if the user puts down a finger, it uses the event regions to figure out if (a) it can handle scrolling right away, or (b) it needs to wait for the main thread to do a full hit-test and tell it what really got hit or (c) it can handle scrolling right away but with additional directional constraints per the touch-action spec. (a) and (b) also apply to wheel events.

For cursor information I don't think we want to reuse this structure, I just pointed it out as something similar to what we would need. Note that the region operations needed to populate this structure tend to be expensive and show up in profiles. I expect the same would be true of cursor regions.

[1] http://searchfox.org/mozilla-central/rev/2142de26c16c05f23e543be4fa1a651c4d29604e/gfx/layers/LayersTypes.h#162