Bug 236671 - Allow downcast<> to work with ImageBufferBackends that support sharing
Summary: Allow downcast<> to work with ImageBufferBackends that support sharing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Process Model (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-02-15 14:53 PST by Simon Fraser (smfr)
Modified: 2022-02-17 09:54 PST (History)
4 users (show)

See Also:


Attachments
Patch (25.59 KB, patch)
2022-02-15 14:59 PST, Simon Fraser (smfr)
sabouhallawa: review+
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (27.91 KB, patch)
2022-02-15 20:08 PST, Simon Fraser (smfr)
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (27.91 KB, patch)
2022-02-15 22:50 PST, Simon Fraser (smfr)
no flags Details | Formatted Diff | Diff
Patch (67.63 KB, patch)
2022-02-16 16:03 PST, Simon Fraser (smfr)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2022-02-15 14:53:53 PST
Allow downcast<> to work with ImageBufferBackends that support sharing
Comment 1 Simon Fraser (smfr) 2022-02-15 14:59:28 PST
Created attachment 452095 [details]
Patch
Comment 2 Said Abou-Hallawa 2022-02-15 15:49:47 PST
Comment on attachment 452095 [details]
Patch

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

> Source/WebCore/platform/graphics/ImageBufferBackend.h:143
> +    virtual ImageBufferBackendSharing* toBackendSharing() { return nullptr; }

It is sad that we can't make ImageBufferBackend inherit ImageBufferBackendSharing and have to introduce such function to avoid the diamond inheritance problem.

> Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:119
> +    auto handleFromBuffer = [](WebCore::ImageBuffer& buffer) -> std::optional<ImageBufferBackendHandle> {

This is definitely cleaner and safer than the existing code. But we still have to deal with the backend and have to downcast it. Is there a way to move this call to ImageBuffer such that this code can be replaced by a single call?

> Source/WebKit/WebProcess/GPU/graphics/ImageBufferBackendHandleSharing.h:37
> +    virtual ImageBufferBackendHandle createBackendHandle() const = 0;

Can these functions in ImageBuffer/ImageBufferBackend also be moved to this class?

    virtual bool isInUse() const = 0;
    virtual void releaseGraphicsContext() = 0;
    virtual void releaseBufferToPool() = 0;

    // Returns true on success.
    virtual bool setVolatile() = 0;
    virtual VolatilityState setNonVolatile() = 0;

    virtual std::unique_ptr<ThreadSafeImageBufferFlusher> createFlusher() = 0;

I think they are specific to WebKit and they are only used by RemoteLayerBackingStore.

> Source/WebKit/WebProcess/GPU/graphics/ImageBufferBackendHandleSharing.h:45
> +SPECIALIZE_TYPE_TRAITS_IMAGE_BUFFER_BACKEND_SHARING(WebKit::ImageBufferBackendHandleSharing, isImageBufferBackendHandleSharing())

SPECIALIZE_TYPE_TRAITS_IMAGE_BUFFER_BACKEND_SHARING() is defined in ImageBufferBackend.h and it is only used here. Why do not we move the macro here also?
Comment 3 Simon Fraser (smfr) 2022-02-15 20:08:44 PST
Created attachment 452127 [details]
Patch
Comment 4 Simon Fraser (smfr) 2022-02-15 20:33:59 PST
(In reply to Said Abou-Hallawa from comment #2)
> Comment on attachment 452095 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=452095&action=review
> 
> > Source/WebCore/platform/graphics/ImageBufferBackend.h:143
> > +    virtual ImageBufferBackendSharing* toBackendSharing() { return nullptr; }
> 
> It is sad that we can't make ImageBufferBackend inherit
> ImageBufferBackendSharing and have to introduce such function to avoid the
> diamond inheritance problem.

Indeed.

> > Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:119
> > +    auto handleFromBuffer = [](WebCore::ImageBuffer& buffer) -> std::optional<ImageBufferBackendHandle> {
> 
> This is definitely cleaner and safer than the existing code. But we still
> have to deal with the backend and have to downcast it. Is there a way to
> move this call to ImageBuffer such that this code can be replaced by a
> single call?

ImageBuffer (in WebCore) can't know about ImageBufferBackendHandle (in WebKit).
> 
> > Source/WebKit/WebProcess/GPU/graphics/ImageBufferBackendHandleSharing.h:37
> > +    virtual ImageBufferBackendHandle createBackendHandle() const = 0;
> 
> Can these functions in ImageBuffer/ImageBufferBackend also be moved to this
> class?
> 
>     virtual bool isInUse() const = 0;
>     virtual void releaseGraphicsContext() = 0;
>     virtual void releaseBufferToPool() = 0;
> 
>     // Returns true on success.
>     virtual bool setVolatile() = 0;
>     virtual VolatilityState setNonVolatile() = 0;
> 
>     virtual std::unique_ptr<ThreadSafeImageBufferFlusher> createFlusher() =
> 0;
> 
> I think they are specific to WebKit and they are only used by
> RemoteLayerBackingStore.

Maybe but not in this patch.

> > Source/WebKit/WebProcess/GPU/graphics/ImageBufferBackendHandleSharing.h:45
> > +SPECIALIZE_TYPE_TRAITS_IMAGE_BUFFER_BACKEND_SHARING(WebKit::ImageBufferBackendHandleSharing, isImageBufferBackendHandleSharing())
> 
> SPECIALIZE_TYPE_TRAITS_IMAGE_BUFFER_BACKEND_SHARING() is defined in
> ImageBufferBackend.h and it is only used here. Why do not we move the macro
> here also?

Generally we put the "#define SPECIALIZE_TYPE_TRAITS_IMAGE_BUFFER_BACKEND_SHARING()" macro in the base class file, but I can move it.
Comment 5 Simon Fraser (smfr) 2022-02-15 22:50:06 PST
Created attachment 452148 [details]
Patch
Comment 6 EWS 2022-02-16 10:37:09 PST
Committed r289911 (247341@main): <https://commits.webkit.org/247341@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 452148 [details].
Comment 7 Radar WebKit Bug Importer 2022-02-16 10:38:16 PST
<rdar://problem/89034498>
Comment 8 Simon Fraser (smfr) 2022-02-16 16:03:07 PST
Reopening to attach new patch.
Comment 9 Simon Fraser (smfr) 2022-02-16 16:03:08 PST
Created attachment 452266 [details]
Patch
Comment 10 Simon Fraser (smfr) 2022-02-17 09:54:20 PST
Patch added by mistake.