Bug 255076 – Add PaintPhase::Accessibility and AccessibilityRegionContext to enable AX element bounding-box caching

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Tyler Wilcock]

Accessibility needs to cache the bounding box of non-accessibility-is-ignored elements on the secondary AX thread. We can use paint to get this geometry.

[Radar WebKit Bug Importer]

<rdar://problem/107694492>

[Tyler Wilcock]

Created attachment 465792 [details]
Patch

[Tyler Wilcock]

Created attachment 465793 [details]
Patch

[Tyler Wilcock]

Created attachment 465795 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 465795 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=465795&action=review

The approach is good. Let’s get the naming right.

> Source/WebCore/page/LocalFrameView.cpp:4686
> +    traverseForPaintInvalidation(NullGraphicsContext::PaintInvalidationReasons::InvalidatingAccessibilityObjectRects, &accessibilityPaintContext);

There’s a naming conflict here, and I think you’ve adopted the “invalidating” term too literally. This isn’t a “invalidate the accessibility rects” paint pass, it’s a “generate the accessibility rects”. So calling “traverseForPaintInvalidation” doesn’t make sense here, suggesting we rename “traverseForPaintInvalidation()” to something like “traverseForUtilityPaint”.

PaintInvalidationReasons should also be renamed.

“Utility paint” is not a great name. We should think of a better one.

> Source/WebCore/rendering/PaintContext.h:36
> +class PaintContext : public CanMakeCheckedPtr {

This would be a UtilityPaintContext or something (it’s explicitly *not* a paint context).

> Source/WebCore/rendering/RenderLayer.cpp:3176
> +    bool isCollectingAccessibilityRects = context.invalidatingAccessibilityObjectRects();

This is where the mis-naming is obvious.

[Simon Fraser (smfr)]

I see that the callers of LocalFrameView::traverseForPaintInvalidation() are LocalFrameView::invalidateControlTints() and LocalFrameView::invalidateImagesWithAsyncDecodes().

The non-invalidation one is ContentfulPaintChecker, which just calls paint() directly:

    NullGraphicsContext checkerContext(NullGraphicsContext::PaintInvalidationReasons::DetectingContentfulPaint);
    frameView.paint(checkerContext, frameView.renderView()->documentRect());

Maybe that’s the way to go for accessibility rects.

[Tyler Wilcock]

Created attachment 465945 [details]
Patch

[Tyler Wilcock]

> The non-invalidation one is ContentfulPaintChecker, which just calls paint()
> directly:
> 
>     NullGraphicsContext
> checkerContext(NullGraphicsContext::PaintInvalidationReasons::
> DetectingContentfulPaint);
>     frameView.paint(checkerContext, frameView.renderView()->documentRect());
> 
> Maybe that’s the way to go for accessibility rects.
Thanks, implemented this.

As far as the name for what is currently called "PaintContext". There are two consumers of this context — event regions and accessibility. And both do very similar things: use the paint traversal to get final geometry for use in a non-directly-graphical way.

So maybe this type of paint is a "geometry traversal paint", making this a GeometryTraversalContext?



Thoughts or other ideas?



Latest patch uses GeometryTraversalContext in case seeing the name in context helps — happy to change further if needed.

[chris fleizach]

(In reply to Tyler Wilcock from comment #8)
> > The non-invalidation one is ContentfulPaintChecker, which just calls paint()
> > directly:
> > 
> >     NullGraphicsContext
> > checkerContext(NullGraphicsContext::PaintInvalidationReasons::
> > DetectingContentfulPaint);
> >     frameView.paint(checkerContext, frameView.renderView()->documentRect());
> > 
> > Maybe that’s the way to go for accessibility rects.
> Thanks, implemented this.
> 
> As far as the name for what is currently called "PaintContext". There are
> two consumers of this context — event regions and accessibility. And both do
> very similar things: use the paint traversal to get final geometry for use
> in a non-directly-graphical way.
> 
> So maybe this type of paint is a "geometry traversal paint", making this a
> GeometryTraversalContext?
> 
> 

Thoughts or other ideas?
> 
> 

Latest patch uses GeometryTraversalContext in case seeing the name in
> context helps — happy to change further if needed.

Wonder if a better name would be

RegionContext, 

which then can be either the existing EventRegionContext object or a new AccessibilityRegionContext.

[Tyler Wilcock]

Created attachment 466114 [details]
Patch

[Tyler Wilcock]

(In reply to chris fleizach from comment #9)
> (In reply to Tyler Wilcock from comment #8)
> > > The non-invalidation one is ContentfulPaintChecker, which just calls paint()
> > > directly:
> > > 
> > >     NullGraphicsContext
> > > checkerContext(NullGraphicsContext::PaintInvalidationReasons::
> > > DetectingContentfulPaint);
> > >     frameView.paint(checkerContext, frameView.renderView()->documentRect());
> > > 
> > > Maybe that’s the way to go for accessibility rects.
> > Thanks, implemented this.
> > 
> > As far as the name for what is currently called "PaintContext". There are
> > two consumers of this context — event regions and accessibility. And both do
> > very similar things: use the paint traversal to get final geometry for use
> > in a non-directly-graphical way.
> > 
> > So maybe this type of paint is a "geometry traversal paint", making this a
> > GeometryTraversalContext?
> > 
> > 

Thoughts or other ideas?
> > 
> > 

Latest patch uses GeometryTraversalContext in case seeing the name in
> > context helps — happy to change further if needed.
> 
> Wonder if a better name would be
> 
> RegionContext, 
> 
> which then can be either the existing EventRegionContext object or a new
> AccessibilityRegionContext.
OK, made this change, so should be ready to review again.

[chris fleizach]

(In reply to Tyler Wilcock from comment #11)
> (In reply to chris fleizach from comment #9)
> > (In reply to Tyler Wilcock from comment #8)
> > > > The non-invalidation one is ContentfulPaintChecker, which just calls paint()
> > > > directly:
> > > > 
> > > >     NullGraphicsContext
> > > > checkerContext(NullGraphicsContext::PaintInvalidationReasons::
> > > > DetectingContentfulPaint);
> > > >     frameView.paint(checkerContext, frameView.renderView()->documentRect());
> > > > 
> > > > Maybe that’s the way to go for accessibility rects.
> > > Thanks, implemented this.
> > > 
> > > As far as the name for what is currently called "PaintContext". There are
> > > two consumers of this context — event regions and accessibility. And both do
> > > very similar things: use the paint traversal to get final geometry for use
> > > in a non-directly-graphical way.
> > > 
> > > So maybe this type of paint is a "geometry traversal paint", making this a
> > > GeometryTraversalContext?
> > > 
> > > 

Thoughts or other ideas?
> > > 
> > > 

Latest patch uses GeometryTraversalContext in case seeing the name in
> > > context helps — happy to change further if needed.
> > 
> > Wonder if a better name would be
> > 
> > RegionContext, 
> > 
> > which then can be either the existing EventRegionContext object or a new
> > AccessibilityRegionContext.
> OK, made this change, so should be ready to review again.

Looks pretty good to me

[EWS]

Committed 263493@main (6fa5a22eeca9): <https://commits.webkit.org/263493@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 466114 [details].