[CTW] Consider not caching opacity if it is 1.0
Categories
(Core :: Disability Access APIs, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox108 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
Attachments
(2 files)
Opacity defaults to 1.0. Right now, we cache it for every Accessible except Accessibles that have no frame, even if it is 1.0. This wastes space in the cache for a value which will be the default for the vast majority of Accessibles.
The only Accessibles we cache that have no frame are display: contents. Even though display: contents is technically not visible itself, its contents are, so treating it as non-opaque seems semantically weird anyway.
I propose that we assume a default of 1.0 unless explicitly overridden.
Assignee | ||
Comment 1•2 years ago
|
||
Previously, it was possible to have no value, but only for Accessibles without frames.
That effectively means display: contents, and since the content is visible (even though the element itself doesn't have a box), exposing it as non-opaque isn't important and arguably doesn't make sense.
This way, we avoid awastefully caching 1.0 for the vast majority of Accessibles.
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
The primary intent of the first patch here was to avoid memory wasted by caching default opacity values.
Unfortunately, this was defeated by the fact that we previously sent DeleteEntry for initial cache updates of opacity.
This resulted in DeleteEntry being stored in the parent process cache, since DeleteEntry is only handled specially for cache updates, not initial pushes.
We now only send DeleteEntry for cache updates, which is consistent with what we do for other cache attributes.
While fixing this, I discovered that we made the same mistake for table cell headers, so I fixed that as well.
Comment 4•2 years ago
|
||
bugherder |
Comment 6•2 years ago
|
||
bugherder |
Description
•