Bug 218259 – [Concurrent display lists] Add alternate versions of existing display list items that only contain inline data

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Wenson Hsieh]

- StrokeInlinePath
- FillInlinePath
- SetStrokeThickness
- SetInlineFillColor
- SetInlineStrokeColor
- SetInlineFillGradient

[Wenson Hsieh]

Created attachment 412477 [details]
Patch

[Wenson Hsieh]

Created attachment 412478 [details]
For EWS

[Wenson Hsieh]

(whoops, looks like I missed a SPECIALIZE_TYPE_TRAITS_DISPLAYLIST_ITEM for SetInlineFillGradient in this patch)

[Wenson Hsieh]

Created attachment 412486 [details]
Fix builds

[EWS]

Committed r269092: <https://trac.webkit.org/changeset/269092>

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

[Radar WebKit Bug Importer]

<rdar://problem/70748246>

[Sam Weinig]

Since I don't recall seeing any references to what [Concurrent display lists] are, can you please explain what this feature is, and how you intend to go about implementing it?

[Wenson Hsieh]

(In reply to Sam Weinig from comment #7)
> Since I don't recall seeing any references to what [Concurrent display
> lists] are, can you please explain what this feature is, and how you intend
> to go about implementing it?

This "feature" is supporting concurrent generation of display list items in the web process and consumption of display list items in the GPU process.

Our overarching vision to achieve this is to make all of our display list items contain only PoD types, and store them directly in memory shared between the web and GPU processes.

Upon pushing items into shared memory in the web process, the web process will notify the GPU process, which will read items out of shared memory (and continue doing so until there are no more items left to be read).

[Sam Weinig]

(In reply to Wenson Hsieh from comment #8)
> (In reply to Sam Weinig from comment #7)
> > Since I don't recall seeing any references to what [Concurrent display
> > lists] are, can you please explain what this feature is, and how you intend
> > to go about implementing it?
> 
> This "feature" is supporting concurrent generation of display list items in
> the web process and consumption of display list items in the GPU process.
> 
> Our overarching vision to achieve this is to make all of our display list
> items contain only PoD types, and store them directly in memory shared
> between the web and GPU processes.
> 
> Upon pushing items into shared memory in the web process, the web process
> will notify the GPU process, which will read items out of shared memory (and
> continue doing so until there are no more items left to be read).

Sounds reasonable. What is the plan for things that can't be directly encoded, like IOSurfaces?

[Wenson Hsieh]

(In reply to Sam Weinig from comment #9)
> (In reply to Wenson Hsieh from comment #8)
> > (In reply to Sam Weinig from comment #7)
> > > Since I don't recall seeing any references to what [Concurrent display
> > > lists] are, can you please explain what this feature is, and how you intend
> > > to go about implementing it?
> > 
> > This "feature" is supporting concurrent generation of display list items in
> > the web process and consumption of display list items in the GPU process.
> > 
> > Our overarching vision to achieve this is to make all of our display list
> > items contain only PoD types, and store them directly in memory shared
> > between the web and GPU processes.
> > 
> > Upon pushing items into shared memory in the web process, the web process
> > will notify the GPU process, which will read items out of shared memory (and
> > continue doing so until there are no more items left to be read).
> 
> Sounds reasonable. What is the plan for things that can't be directly
> encoded, like IOSurfaces?

I would think IOSurfaces would exist in the GPUP already, so an identifier (and possibly some additional metadata) should be sufficient.

More generally, our current thinking is to add a special display list item that represents mapping an identifier to a resource encoded directly in shared memory, and making display list items reference the resource via the identifier.