Bug 236233 - [model] improve sizing on macOS
Summary: [model] improve sizing on macOS
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antoine Quint
URL:
Keywords: InRadar
Depends on:
Blocks: 236234
  Show dependency treegraph
 
Reported: 2022-02-07 06:54 PST by Antoine Quint
Modified: 2022-02-09 12:21 PST (History)
11 users (show)

See Also:


Attachments
Patch (24.37 KB, patch)
2022-02-07 07:06 PST, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (24.22 KB, patch)
2022-02-09 04:18 PST, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (25.72 KB, patch)
2022-02-09 10:39 PST, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch for landing (25.66 KB, patch)
2022-02-09 11:41 PST, Antoine Quint
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Quint 2022-02-07 06:54:16 PST
[model] improve sizing on macOS
Comment 1 Radar WebKit Bug Importer 2022-02-07 06:55:07 PST
<rdar://problem/88569881>
Comment 2 Antoine Quint 2022-02-07 07:06:07 PST
Created attachment 451092 [details]
Patch
Comment 3 Antoine Quint 2022-02-07 07:06:13 PST
<rdar://problem/88569881>
Comment 4 Dean Jackson 2022-02-07 07:47:54 PST
Comment on attachment 451092 [details]
Patch

Can you make a test? Otherwise it looks good.
Comment 5 Dean Jackson 2022-02-07 07:47:55 PST
Comment on attachment 451092 [details]
Patch

Can you make a test? Otherwise it looks good.
Comment 6 Antoine Quint 2022-02-07 08:04:39 PST
This sets the size in ways that are internal to ARQL, I don't think we can test this.
Comment 7 Tim Horton 2022-02-07 09:00:28 PST
Comment on attachment 451092 [details]
Patch

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

> Source/WebKit/ChangeLog:13
> +        In that new method, we call -[ASVInlinePreview updateFrame:completionHandler:] which provies us with a

`provies`

> Source/WebCore/rendering/RenderLayerBacking.cpp:1520
> +    else if (is<RenderModel>(renderer())) {
> +        auto* element = downcast<HTMLModelElement>(renderer().element());
> +        if (element->usesPlatformLayer())
> +            element->parentLayerSizeMayHaveChanged(m_graphicsLayer->size());
> +    }

This one-off model-only communication about layer size (and in an `else if` about something entirely different?) seems unfortunate. Maybe see if Simon has a better way.
Comment 8 Antoine Quint 2022-02-07 09:28:45 PST
(In reply to Tim Horton from comment #7)
> Comment on attachment 451092 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=451092&action=review
> 
> > Source/WebCore/rendering/RenderLayerBacking.cpp:1520
> > +    else if (is<RenderModel>(renderer())) {
> > +        auto* element = downcast<HTMLModelElement>(renderer().element());
> > +        if (element->usesPlatformLayer())
> > +            element->parentLayerSizeMayHaveChanged(m_graphicsLayer->size());
> > +    }
> 
> This one-off model-only communication about layer size (and in an `else if`
> about something entirely different?) seems unfortunate. Maybe see if Simon
> has a better way.

Sadly, we already do something similar in RenderLayerBacking::updateConfiguration().
Comment 9 Simon Fraser (smfr) 2022-02-07 09:45:06 PST
Comment on attachment 451092 [details]
Patch

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

> Source/WebCore/rendering/RenderLayerBacking.cpp:1516
> +    else if (is<RenderModel>(renderer())) {

Do you really want this to be the `else` clause of `subpixelOffsetFromRendererChanged()`? Doesn't make much sense.

>>> Source/WebCore/rendering/RenderLayerBacking.cpp:1520
>>> +    }
>> 
>> This one-off model-only communication about layer size (and in an `else if` about something entirely different?) seems unfortunate. Maybe see if Simon has a better way.
> 
> Sadly, we already do something similar in RenderLayerBacking::updateConfiguration().

It's weird to read m_graphicsLayer->size() here. RenderLayerBacking controls the size fo the GraphicsLayer, so it makes more sense to get it from RenderBox here.
Comment 10 Antoine Quint 2022-02-09 04:18:04 PST
Created attachment 451356 [details]
Patch
Comment 11 Simon Fraser (smfr) 2022-02-09 09:20:17 PST
Comment on attachment 451356 [details]
Patch

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

> Source/WebCore/Modules/model-element/HTMLModelElement.h:161
> +    FloatSize m_platformLayerSize;

Very weird to store this presentation-related thing on a DOM element class. Also weird that it refers to platform layers; sizing is controlled by CSS, so this should just talk about "contentBoxSize" or something.

> Source/WebCore/rendering/RenderLayerBacking.cpp:1539
> +            element->parentLayerSizeMayHaveChanged(primaryGraphicsLayerRect.size());

The primary graphics layer for the model element has a size that's affected by borders, padding, box-shadow etc. It doesn't seem right to use this size. Make a test with a big box-shadow to test.
Comment 12 Antoine Quint 2022-02-09 09:59:09 PST
(In reply to Simon Fraser (smfr) from comment #11)
> Comment on attachment 451356 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=451356&action=review
> 
> > Source/WebCore/Modules/model-element/HTMLModelElement.h:161
> > +    FloatSize m_platformLayerSize;
> 
> Very weird to store this presentation-related thing on a DOM element class.
> Also weird that it refers to platform layers; sizing is controlled by CSS,
> so this should just talk about "contentBoxSize" or something.

I think we can store this on ARKitInlinePreviewModelPlayerMac.

> > Source/WebCore/rendering/RenderLayerBacking.cpp:1539
> > +            element->parentLayerSizeMayHaveChanged(primaryGraphicsLayerRect.size());
> 
> The primary graphics layer for the model element has a size that's affected
> by borders, padding, box-shadow etc. It doesn't seem right to use this size.
> Make a test with a big box-shadow to test.

OK. How would I go about getting the size for the content to be presented?
Comment 13 Antoine Quint 2022-02-09 10:39:42 PST
Created attachment 451402 [details]
Patch
Comment 14 Simon Fraser (smfr) 2022-02-09 10:55:26 PST
Comment on attachment 451402 [details]
Patch

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

> Source/WebCore/Modules/model-element/HTMLModelElement.cpp:647
> +LayoutSize HTMLModelElement::platformLayerSize() const

Don't use the term "platform layer" here. Maybe contentsSize.

> Source/WebCore/Modules/model-element/HTMLModelElement.h:108
> +    void parentLayerSizeMayHaveChanged();

Why does DOM code care about "parent layer" stuff?

> Source/WebCore/Modules/model-element/HTMLModelElement.h:151
> +    LayoutSize platformLayerSize() const;

Rename

> Source/WebKit/UIProcess/Cocoa/ModelElementControllerCocoa.mm:273
> +            auto fenceSendRight = MachSendRight::adopt([strongFenceHandle copyPort]);
> +            [strongFenceHandle invalidate];

This looks weird but I don't understand how CAFenceHandle and MachSendRights interact

> Source/WebKit/UIProcess/ModelElementController.h:74
> +    void modelElementSizeDidChange(const String& uuid, WebCore::FloatSize, CompletionHandler<void(Expected<MachSendRight, WebCore::ResourceError>)>&&);

You should name the MachSendRight so reading the code I know it's about fencing.

> Source/WebKit/WebProcess/Model/mac/ARKitInlinePreviewModelPlayerMac.mm:180
> +void ARKitInlinePreviewModelPlayerMac::sizeDidChange(WebCore::LayoutSize size)

I feel like size should be a FloatSize, and we should have pixel-snapped it somewhere.
Comment 15 Antoine Quint 2022-02-09 11:31:28 PST
(In reply to Simon Fraser (smfr) from comment #14)
> Comment on attachment 451402 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=451402&action=review
> 
> > Source/WebCore/Modules/model-element/HTMLModelElement.cpp:647
> > +LayoutSize HTMLModelElement::platformLayerSize() const
> 
> Don't use the term "platform layer" here. Maybe contentsSize.

Will rename to contentSize.

> > Source/WebCore/Modules/model-element/HTMLModelElement.h:108
> > +    void parentLayerSizeMayHaveChanged();
> 
> Why does DOM code care about "parent layer" stuff?

Doesn't, I'll rename to "sizeMayHaveChanged()".

> > Source/WebKit/UIProcess/Cocoa/ModelElementControllerCocoa.mm:273
> > +            auto fenceSendRight = MachSendRight::adopt([strongFenceHandle copyPort]);
> > +            [strongFenceHandle invalidate];
> 
> This looks weird but I don't understand how CAFenceHandle and MachSendRights
> interact

Tim Horton helped me with this, so I trust that it's correct.

> > Source/WebKit/UIProcess/ModelElementController.h:74
> > +    void modelElementSizeDidChange(const String& uuid, WebCore::FloatSize, CompletionHandler<void(Expected<MachSendRight, WebCore::ResourceError>)>&&);
> 
> You should name the MachSendRight so reading the code I know it's about
> fencing.

I tried and failed: "error: type-id cannot have a name".

> > Source/WebKit/WebProcess/Model/mac/ARKitInlinePreviewModelPlayerMac.mm:180
> > +void ARKitInlinePreviewModelPlayerMac::sizeDidChange(WebCore::LayoutSize size)
> 
> I feel like size should be a FloatSize, and we should have pixel-snapped it
> somewhere.

This is something I'd like to look at as a follow-up, filed bug 236388.
Comment 16 Antoine Quint 2022-02-09 11:41:08 PST
Created attachment 451419 [details]
Patch for landing
Comment 17 EWS 2022-02-09 12:21:17 PST
Committed r289495 (247033@main): <https://commits.webkit.org/247033@main>

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