⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Timeline



Dec 6, 2020:

9:43 PM Changeset in webkit [270495] by Diego Pino Garcia
  • 3 edits in trunk/LayoutTests

[WPE] Unreviewed test gardening. Follow-up r270469, media-source timeouts.

Also gardened flaky failure in imported/w3c/web-platform-tests/xhr/event-timeout.any.html.

  • platform/glib/TestExpectations:
  • platform/wpe/TestExpectations:
8:54 PM Changeset in webkit [270494] by jh718.park@samsung.com
  • 2 edits in trunk/Source/WebCore

Unreviewed. Remove the build warning below since r270414.
warning: redundant move in return statement [-Wredundant-move]

No new tests, no new behaviors.

  • contentextensions/NFAToDFA.cpp:

(WebCore::ContentExtensions::NFAToDFA::convert):

8:31 PM Changeset in webkit [270493] by jh718.park@samsung.com
  • 2 edits in trunk/Source/WebCore

Unreviewed. Remove the build warnings below since r270400.
warning: unused parameter ‘foo’ [-Wunused-parameter]

No new tests, no new behaviors.

  • platform/graphics/opengl/GraphicsContextGLOpenGLCommon.cpp:

(WebCore::GraphicsContextGLOpenGL::getActiveUniforms):

7:03 PM Changeset in webkit [270492] by Lauro Moura
  • 3 edits in trunk/LayoutTests

[GLIB] Gardening wheel and webgl failures

Unreviewed test gardening.

  • platform/glib/TestExpectations:
  • platform/gtk/TestExpectations:
4:49 PM Changeset in webkit [270491] by Simon Fraser
  • 4 edits in trunk/Source/WebCore

Use WTF_MAKE_FAST_ALLOCATED for some scrolling-related objects
​https://bugs.webkit.org/show_bug.cgi?id=219567

Reviewed by Tim Horton.

Make ScrollingCoordinator, ScrollingTree and ScrollingTreeNode be fast-allocated.

  • page/scrolling/ScrollingCoordinator.h:
  • page/scrolling/ScrollingTree.h:
  • page/scrolling/ScrollingTreeNode.h:
4:35 PM Changeset in webkit [270490] by Simon Fraser
  • 5 edits
    2 moves
    1 add in trunk/Source/WebCore

[LFC Display] Move DisplayLayerController to display/compositing
​https://bugs.webkit.org/show_bug.cgi?id=219584

Reviewed by Anders Carlsson.

Make a display/compositing directory and move DisplayLayerController.* into it.

  • CMakeLists.txt:
  • Sources.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • display/compositing/DisplayLayerController.cpp: Renamed from Source/WebCore/display/DisplayLayerController.cpp.
  • display/compositing/DisplayLayerController.h: Renamed from Source/WebCore/display/DisplayLayerController.h.
1:42 PM Changeset in webkit [270489] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebKit

[WebKit] Fix use of std::max_align_t
​https://bugs.webkit.org/show_bug.cgi?id=219579

Patch by Samuel Thibault <​samuel.thibault@ens-lyon.org> on 2020-12-06
Reviewed by Fujii Hironori.

Standard says that it's alignof(std::max_align_t) that should be used,
not its size, e.g.
​https://en.cppreference.com/w/cpp/types/max_align_t
and indeed at least with gcc 10's stddef.h, max_align_t is a structure
containing a long long, a long double, and a float18, thus not a power
of two.

  • Shared/SharedDisplayListHandle.h:

(WebKit::SharedDisplayListHandle::headerSize): Use
alignof(std::max_align_t) instead of sizeof(std::max_align_t).

1:31 PM Changeset in webkit [270488] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WTF

[WTF] Add Unix-generic way of determining the available RAM
​https://bugs.webkit.org/show_bug.cgi?id=219570
sysconf(_SC_PHYS_PAGES) and sysconf(_SC_PAGE_SIZE) are a very generic way to get

Patch by Samuel Thibault <​samuel.thibault@ens-lyon.org> on 2020-12-06
Reviewed by Fujii Hironori.

  • wtf/RAMSize.cpp:

(WTF::computeRAMSize): Fallback to sysconf to determine RAM size.

12:41 PM Changeset in webkit [270487] by ysuzuki@apple.com
  • 4 edits
    2 adds in trunk

[JSC] get / set for object literal and class should not be escaped
​https://bugs.webkit.org/show_bug.cgi?id=219576

Reviewed by Alexey Shvayka.

JSTests:

  • stress/escaped-getter-setter-in-class.js: Added.

(testSyntaxError):
(testSyntaxError.String.raw.A.prototype.u0067.u0065.u0074.m):
(testSyntaxError.String.raw.A):
(testSyntaxError.String.raw.A.prototype.u0073.u0065.u0074.m):

  • stress/escaped-getter-setter-in-object.js: Added.

(testSyntaxError):
(testSyntaxError.String.raw.u0067.u0065.u0074.m):
(testSyntaxError.String.raw.u0073.u0065.u0074.m):

  • test262/expectations.yaml:

Source/JavaScriptCore:

"get" and "set" for getter and setter should not be escaped one.
Terminal symbols of the lexical grammars are shown in fixed width font [1],
and are to appear in a script exactly as written.

[1]: ​https://tc39.es/ecma262/#sec-method-definitions

  • parser/Parser.cpp:

(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):

11:21 AM Changeset in webkit [270486] by youenn@apple.com
  • 14 edits in trunk

Add support for RTCRtpSender::setStreams
​https://bugs.webkit.org/show_bug.cgi?id=219542

Reviewed by Eric Carlson.

LayoutTests/imported/w3c:

  • web-platform-tests/webrtc/RTCPeerConnection-setRemoteDescription-rollback-expected.txt:
  • web-platform-tests/webrtc/RTCRtpSender-setStreams.https-expected.txt:

Source/WebCore:

Pipe stream IDs from WebCore sender to libqebrtc backend sender.
A follow-up patch should handle creation of remote streams in case of renegotiation.
Covered by updated and rebased tests.

  • Modules/mediastream/RTCRtpSender.cpp:

(WebCore::RTCRtpSender::create):
(WebCore::RTCRtpSender::RTCRtpSender):
(WebCore::RTCRtpSender::setStreams):
(WebCore::RTCRtpSender::setMediaStreamIds):

  • Modules/mediastream/RTCRtpSender.h:
  • Modules/mediastream/RTCRtpSender.idl:
  • Modules/mediastream/RTCRtpSenderBackend.h:
  • Modules/mediastream/libwebrtc/LibWebRTCPeerConnectionBackend.cpp:

(WebCore::LibWebRTCPeerConnectionBackend::addTrack):
(WebCore::LibWebRTCPeerConnectionBackend::addTransceiverFromTrackOrKind):
(WebCore::LibWebRTCPeerConnectionBackend::newRemoteTransceiver):

  • Modules/mediastream/libwebrtc/LibWebRTCRtpSenderBackend.cpp:

(WebCore::LibWebRTCRtpSenderBackend::setMediaStreamIds):

  • Modules/mediastream/libwebrtc/LibWebRTCRtpSenderBackend.h:

LayoutTests:

  • webrtc/video.html:
10:58 AM Changeset in webkit [270485] by Alan Bujtas
  • 4 edits in trunk/Source/WebCore

[LFC][IFC] BoxGeometry should provide an enclosing rect for multiline inline boxes
​https://bugs.webkit.org/show_bug.cgi?id=219574

Reviewed by Antti Koivisto.

This patch add support for multiline inline box geometry (e.g. <span>first<br>second</span>)
In such cases we turn the content box into the enclosing rect (border and padding do not make too much sense in multiline case)
This is not to be confused with Element.getClientRects() which returns a list of rects where border and padding start making sense.

  • layout/inlineformatting/InlineFormattingContext.cpp:

(WebCore::Layout::InlineFormattingContext::computeGeometryForLineContent):
set the box geometry depending on whether this is the first line where the inline box shows or we are processing an in-between or end line.

  • layout/integration/LayoutIntegrationLineLayout.cpp:

(WebCore::LayoutIntegration::LineLayout::enclosingBorderBoxRectFor const):

  • layout/layouttree/LayoutGeometryRect.h:

(WebCore::Layout::Rect::moveBy):
(WebCore::Layout::Rect::expandToContain):

10:47 AM Changeset in webkit [270484] by Simon Fraser
  • 10 edits in trunk/Source/WebCore

[LFC Display] Move border radii to BoxRareGeometry
​https://bugs.webkit.org/show_bug.cgi?id=219581

Reviewed by Zalan Bujtas.

Border radius is not a box decoration, since it affects rendering (e.g. clipping)
when there are no decorations, so move it to BoxRareGeometry.

  • display/css/DisplayBoxDecorationData.cpp:

(WebCore::Display::roundedRectWithIncludedRadii): Deleted.
(WebCore::Display::roundedInsetBorderForRect): Deleted.
(WebCore::Display::BoxDecorationData::hasBorderRadius const): Deleted.

  • display/css/DisplayBoxDecorationData.h:

(WebCore::Display::BoxDecorationData::borderRadii const): Deleted.
(WebCore::Display::BoxDecorationData::setBorderRadii): Deleted.

  • display/css/DisplayBoxDecorationPainter.cpp:

(WebCore::Display::BoxDecorationPainter::BoxDecorationPainter):
(WebCore::Display::BoxDecorationPainter::paintBoxShadow const):
(WebCore::Display::BoxDecorationPainter::paintBackground const):
(WebCore::Display::BoxDecorationPainter::determineBackgroundBleedAvoidance):
(WebCore::Display::BoxDecorationPainter::computeBorderRect): Deleted.

  • display/css/DisplayBoxDecorationPainter.h:
  • display/css/DisplayBoxFactory.cpp:

(WebCore::Display::BoxFactory::constructBoxDecorationData const):
(WebCore::Display::BoxFactory::constructBoxRareGeometry const):

  • display/css/DisplayBoxModelBox.cpp:

(WebCore::Display::BoxModelBox::hasBorderRadius const):
(WebCore::Display::BoxModelBox::borderRoundedRect const):
(WebCore::Display::BoxModelBox::innerBorderRoundedRect const):
(WebCore::Display::BoxModelBox::clipForDescendants const):

  • display/css/DisplayBoxModelBox.h:
  • display/css/DisplayBoxRareGeometry.cpp:

(WebCore::Display::BoxRareGeometry::hasBorderRadius const):
(WebCore::Display::roundedRectWithIncludedRadii):
(WebCore::Display::roundedInsetBorderForRect):

  • display/css/DisplayBoxRareGeometry.h:

(WebCore::Display::BoxRareGeometry::borderRadii const):
(WebCore::Display::BoxRareGeometry::setBorderRadii):

6:53 AM Changeset in webkit [270483] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][Integration] Disable RenderCounter content
​https://bugs.webkit.org/show_bug.cgi?id=219573

Reviewed by Antti Koivisto.

RenderCounters are not supported yet.

  • layout/integration/LayoutIntegrationCoverage.cpp:

(WebCore::LayoutIntegration::canUseForChild):

5:38 AM Changeset in webkit [270482] by Lauro Moura
  • 3 edits in trunk/Source/WebKit

Unreviewed. Add missing GPU_PROCESS guards around RemoteMediaEngineConfigurationFactory after r270462
​https://bugs.webkit.org/show_bug.cgi?id=219578

Was breaking the Ubuntu LTS/Debian builds.

  • WebProcess/GPU/media/RemoteMediaEngineConfigurationFactory.cpp:
  • WebProcess/WebProcess.cpp:
12:41 AM Changeset in webkit [270481] by ysuzuki@apple.com
  • 8 edits
    1 add in trunk

[JSC] Accept escaped keywords for class and object property names
​https://bugs.webkit.org/show_bug.cgi?id=219575

Reviewed by Alexey Shvayka.

JSTests:

  • stress/syntax-error-if-escaped-keyword-used-as-target-object-pattern.js: Added.

(testSyntaxError):

  • test262/expectations.yaml:

Source/JavaScriptCore:

In this patch, we accept escaped keywords for class, object, and object pattern property names.

var object = {

bre\u0061k: 42

};

When escaped keyword appears, we produce ESCAPED_KEYWORD with CanBeErrorTokenFlag. Now CanBeErrorTokenFlag
represents "when this token appears in an error condition, possibly this is error token and special message will appear",
instead of saying this token is definitely an error. So we can just use ESCAPED_KEYWORD token to handle this case.

  • parser/Lexer.cpp:

(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):

  • parser/Parser.cpp:

(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::printUnexpectedTokenText):

  • parser/Parser.h:

(JSC::Parser<LexerType>::parse):

  • parser/ParserTokens.h:

Dec 5, 2020:

6:47 PM Changeset in webkit [270480] by Simon Fraser
  • 3 edits in trunk/Source/WebCore

REGRESSION (r268075): Animations at the top of ​https://browserbench.org/JetStream/ are very slow
​https://bugs.webkit.org/show_bug.cgi?id=219447
<rdar://problem/71905123>

Reviewed by Sam Weinig.

SVG images have their own Page, and when they request rendering updates, they have to go through
ChromeClient, but that was missing for the Page::renderingUpdateCompleted() code path.
Make scheduleRenderingUpdateInternal() and call it from the two relevant places.

I tried making both a ref test and a test using internals.renderingUpdateCount(), but neither
were reliable. There's no way to get a signal out from the <img src="*.svg"> to say that
the animation has started, requiring tests to have flakey setTimeouts.

  • page/Page.cpp:

(WebCore::Page::scheduleRenderingUpdate):
(WebCore::Page::scheduleRenderingUpdateInternal):
(WebCore::Page::renderingUpdateCompleted):

  • page/Page.h:
4:22 PM Changeset in webkit [270479] by Said Abou-Hallawa
  • 2 edits in trunk/Source/WebCore

REGRESSION(r270458): Crash loading ​https://browserbench.org/JetStream/
​https://bugs.webkit.org/show_bug.cgi?id=219568

Reviewed by Tim Horton.

Get the backendSize before sinking it into a NativeImage.

  • platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp:

(WebCore::ImageBufferIOSurfaceBackend::drawConsuming):

2:17 PM Changeset in webkit [270478] by Wenson Hsieh
  • 25 edits in trunk

[Concurrent display lists] Synchronize display list rendering across remote image buffers
​https://bugs.webkit.org/show_bug.cgi?id=219091
<rdar://problem/71747695>

Reviewed by Geoff Garen.

Source/WebCore:

See Source/WebKit/ChangeLog for more details.

  • platform/graphics/ImageBuffer.h:
  • platform/graphics/displaylists/DisplayList.cpp:

(WebCore::DisplayList::DisplayList::append):

  • platform/graphics/displaylists/DisplayListItemBuffer.cpp:

(WebCore::DisplayList::ItemHandle::apply):
(WebCore::DisplayList::ItemHandle::destroy):
(WebCore::DisplayList::ItemHandle::copyTo const):
(WebCore::DisplayList::ItemBuffer::swapWritableBufferIfNeeded):

Add plumbing so that didAppendData can inform the client whether the data was appended after switching to a
new buffer. In WebKit2's remote image buffer, we use this information to determine whether or not we need to
send a wakeup message to the GPU process. Namely, in the case of DidChangeItemBuffer::Yes, we don't need to
wake up the GPU process even though the unread bytes count was 0 before we advanced, since the GPU process will
automatically progress to this item buffer when it's done processing items in the previous item buffer.

See WebKit changes (in RemoteImageBufferProxy) for more details.

(WebCore::DisplayList::ItemBuffer::append):
(WebCore::DisplayList::ItemBuffer::didAppendData):
(WebCore::DisplayList::ItemBuffer::appendEncodedData): Deleted.

  • platform/graphics/displaylists/DisplayListItemBuffer.h:

Add a new ItemBufferWritingClient method to inform clients when new bytes are appended to an item buffer,
given the additional number of bytes added and the item buffer handle.

(WebCore::DisplayList::ItemBuffer::append):
(WebCore::DisplayList::ItemBuffer::uncheckedAppend):

  • platform/graphics/displaylists/DisplayListItemType.cpp:

(WebCore::DisplayList::sizeOfItemInBytes):
(WebCore::DisplayList::isDrawingItem):
(WebCore::DisplayList::isInlineItem):

Remove MetaCommandEnd. I introduced this item type because I was going to make the GPU process always sleep for
more display list item data, but I've since changed the approach so that the GPU process goes to sleep naturally
when it's done processing all unread bytes.

  • platform/graphics/displaylists/DisplayListItemType.h:
  • platform/graphics/displaylists/DisplayListItems.cpp:

(WebCore::DisplayList::operator<<):

  • platform/graphics/displaylists/DisplayListItems.h:
  • platform/graphics/displaylists/DisplayListRecorder.h:

(WebCore::DisplayList::Recorder::flushContext):

Add a new helper method to append a FlushContext item via the display list recorder, to ensure that the
appropriate recorder delegate methods are invoked when appending a "flush context" item.

  • platform/graphics/displaylists/DisplayListReplayer.cpp:

(WebCore::DisplayList::Replayer::replay):

  • platform/graphics/displaylists/DisplayListReplayer.h:

Source/WebKit:

Refactors the existing concurrent display list processing mechanism, such that we no longer update the unread
bytes count every 512 items (or when flushing the drawing context), and instead update it every time we append
display list item data. In order to achieve this without making it impossible for multiple display-list backed
image buffers to render simultaneously, we also add support for synchronizing display list items across
different image buffers by using the new meta command items added in bug #219262. As detailed in the ChangeLog
for that bug, a stream of display list data written by the web process and consumed by the GPU process is now
structured like so:

Wakeup message initiates display list processing with Image Buffer A and Item Buffer 1

|
| MetaCommandChangeDestinationImageBuffer(B)
| |
| | MetaCommandChangeItemBuffer(2)
| | |
| | |
v v v
+-----------------------+--------------------------------++
| +--------------------+ +------------------------------+ |
| | Destination | | Destination | | Item Buffer 1
| | Image Buffer A | | Image Buffer B | |
| +--------------------+ +------------------------------+ |
+---------------------------------------------------------+

+---------------------------------------------------------+
| +--------------+ +-----------------------+ |
| | Dst. Image | | Destination Image | Unused | Item Buffer 2
| | Buffer B | | Buffer A | Capacity |
| +--------------+ +-----------------------+ |
+-----------------+-------------------------+-------------+


|
|

MetaCommandChangeDestinationImageBuffer(A)

(Note that the MetaCommandEnd item has been omitted, since we no longer need to explicitly tell the GPU
process to go to sleep with the latest iteration of this patch).

In order to write display list data conforming to this format, we add a mechanism to the web process that keeps
track of the "current destination image buffer" (i.e. the image buffer that has most recently
appended a display list item). Right before this destination is about to change, we append a new
MetaCommandChangeDestinationImageBuffer item before proceeding to append display list items for the new
current destination.

Since we now bump the unread count every time, we need to do some additional work to avoid an excessive number
of wakeups and sleeps in the GPU process, which would otherwise cause a massive regression. To do this, we
introduce an item count hysteresis in the web process, such that we will wait for 512 items to be written before
attempting to send the wakeup message. This allows the web process to get a small head start over the GPU
process, and thus allows the GPU process to be more consistently busy over the course of a single frame.

On the reader (GPU process) side, we make some minor adjustments so that the main display list processing loop
of the GPU process is capable of changing destination image buffers while processing a stream of display list
items.

See below for more details.

  • GPUProcess/graphics/DisplayListReaderHandle.cpp:

(WebKit::DisplayListReaderHandle::advance):

Update advance so that it just performs a single 8-byte atomic exchangeSub rather than grabbing a spinlock.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp:

(WebKit::RemoteRenderingBackend::submit):
(WebKit::RemoteRenderingBackend::nextDestinationImageBufferAfterApplyingDisplayLists):

Rename applyDisplayListsFromHandle to nextDestinationImageBufferAfterApplyingDisplayLists, and make it
return the current image buffer to use as the destination for replaying display list commands. This helper is
still responsible for replaying a display list item buffer until it has no more data (that is, until we
encounter a MetaCommandChangeItemBuffer item informing us of the next item buffer to consume).

(WebKit::RemoteRenderingBackend::wakeUpAndApplyDisplayList):

Adjust this to call nextDestinationImageBufferAfterApplyingDisplayLists.

(WebKit::RemoteRenderingBackend::decodeItem):
(WebKit::RemoteRenderingBackend::applyDisplayListsFromHandle): Deleted.

  • GPUProcess/graphics/RemoteRenderingBackend.h:
  • Shared/SharedDisplayListHandle.h:

Remove SharedDisplayListHandle::Lock altogether, now that we just have a single atomic uint64_t counter to
represent the number of unread bytes.

(WebKit::SharedDisplayListHandle::unreadBytes):
(WebKit::SharedDisplayListHandle::Lock::Lock): Deleted.
(WebKit::SharedDisplayListHandle::Lock::~Lock): Deleted.

  • WebProcess/GPU/graphics/DisplayListWriterHandle.cpp:

(WebKit::DisplayListWriterHandle::advance):

Make this use the single atomic counter, instead of grabbing a spinlock.

(WebKit::DisplayListWriterHandle::moveWritableOffsetToStartIfPossible):
(WebKit::DisplayListWriterHandle::resetWritableOffsetIfPossible): Deleted.

Rename resetWritableOffsetIfPossible to the more accurate moveWritableOffsetToStartIfPossible.

  • WebProcess/GPU/graphics/DisplayListWriterHandle.h:
  • WebProcess/GPU/graphics/RemoteImageBufferProxy.h:

(WebKit::RemoteImageBufferProxy::changeDestinationImageBuffer):

Add a helper method to append a MetaCommandChangeDestinationImageBuffer item to the display list, given the
identifier of this next item buffer.

(WebKit::RemoteImageBufferProxy::clearDisplayList):

Add a helper method to clear the display list, such that the RemoteImageBufferProxy will be asked for a new
buffer handle the next time we append an item.

(WebKit::RemoteImageBufferProxy::waitForDidFlushWithTimeout):

Make this hit the maximum waitForAndDispatchImmediately attempt count and "fail" only if the call to
waitForAndDispatchImmediately actually times out. This change is necessary to ensure that the scenario of
multiple image buffers simultaneously appending display list items works when all image buffers perform (non-
blocking) flushes simultaneously, followed by a sync-wait (blocking) flush. In this situation, the web process
may receive more than three DidFlush messages in rapid succession, causing it to hit this maximum limit of 3
instantly and avoid waiting for the expected DidFlush message to arrive.

(WebKit::RemoteImageBufferProxy::submitDisplayList): Deleted.

  • WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp:

(WebKit::RemoteRenderingBackendProxy::gpuProcessConnectionDidClose):

Reset state when the GPU process is terminated.

(WebKit::RemoteRenderingBackendProxy::willAppendItem):

Update the current destination image buffer (m_currentDestinationImageBufferIdentifier). If this identifier
changed, then we append a MetaCommandChangeDestinationImageBuffer item to the previous destination before
setting the new destination image buffer. We also need to clear the new destination image buffer's display list
before writing new items, to prevent it from overwriting shared display list item data.

(WebKit::RemoteRenderingBackendProxy::sendWakeupMessage):
(WebKit::RemoteRenderingBackendProxy::sendDeferredWakeupMessageIfNeeded):
(WebKit::RemoteRenderingBackendProxy::didAppendData):

Implement a new ItemBufferWritingClient hook by advancing the corresponding item buffer's unread count.
Additionally, schedule a wakeup message in the case where the unread count was zero when we advanced, and the
item buffer we've appended to is not "connected" to a previous item buffer by way of an item buffer change item.

Additionally, in the case where we don't schedule a new wakeup message, check whether or not there is a deferred
wakeup message; if there is, then decrement the remaining item count before we send the wakeup message, and send
the message if the count reaches 0.

(WebKit::RemoteRenderingBackendProxy::findReusableDisplayListHandle):

Pull logic to find a shared display list handle suitable for reuse into a separate helper method, and adjust it
so that if the most recently used display list handle has run out of available capacity, we move it to the end
of the reuse queue and only reuse the new first shared handle in the queue if its writable offset can be reset.
This ensures that the GPU process can always continue reading display list item data from the start of new item
buffers -- i.e., we don't end up with the web process writing out a stream of display list data like:

(Start) Bytes (16, 65520) in ItemBuffer[1]

Bytes (16, 65536) in ItemBuffer[2]
Bytes (65520, 65536) in ItemBuffer[1]

(WebKit::RemoteRenderingBackendProxy::createItemBuffer):
(WebKit::RemoteRenderingBackendProxy::submitDisplayList): Deleted.
(WebKit::RemoteRenderingBackendProxy::updateReusableHandles): Deleted.

  • WebProcess/GPU/graphics/RemoteRenderingBackendProxy.h:

Tools:

  • TestWebKitAPI/Tests/WebCore/DisplayListTests.cpp:

(TestWebKitAPI::TEST):

1:28 PM Changeset in webkit [270477] by Fujii Hironori
  • 62 edits in trunk

Remove ENABLE_GRAPHICS_CONTEXT_GL by replacing it with ENABLE(WEBGL)
​https://bugs.webkit.org/show_bug.cgi?id=219551

Reviewed by Kenneth Russell.

.:

  • Source/CMakeLists.txt:
  • Source/cmake/GStreamerDependencies.cmake:
  • Source/cmake/OptionsFTW.cmake:
  • Source/cmake/OptionsGTK.cmake:
  • Source/cmake/OptionsMac.cmake:
  • Source/cmake/OptionsPlayStation.cmake:
  • Source/cmake/OptionsWPE.cmake:
  • Source/cmake/OptionsWinCairo.cmake:

Source/WebCore:

GraphicsContextGL is a module only for WebGL. ENABLE_WEBGL should
be removed if all ports enable it.

  • CMakeLists.txt:
  • page/Chrome.cpp:

(WebCore::Chrome::windowScreenDidChange):

  • platform/graphics/ANGLEWebKitBridge.cpp:
  • platform/graphics/ANGLEWebKitBridge.h:
  • platform/graphics/FormatConverter.cpp:
  • platform/graphics/FormatConverter.h:
  • platform/graphics/GLContext.cpp:
  • platform/graphics/GLContext.h:
  • platform/graphics/GraphicsContextGL.cpp:
  • platform/graphics/GraphicsContextGL.h:
  • platform/graphics/GraphicsContextGLAttributes.h:
  • platform/graphics/GraphicsContextGLImageExtractor.cpp:
  • platform/graphics/GraphicsContextGLImageExtractor.h:
  • platform/graphics/OpenGLShims.cpp:
  • platform/graphics/angle/ExtensionsGLANGLE.cpp:
  • platform/graphics/angle/GraphicsContextGLANGLE.cpp:
  • platform/graphics/angle/GraphicsContextGLANGLEUtilities.h:
  • platform/graphics/angle/TemporaryANGLESetting.cpp:
  • platform/graphics/cairo/GraphicsContextGLCairo.cpp:
  • platform/graphics/cg/GraphicsContextGLCG.cpp:
  • platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm:
  • platform/graphics/cv/GraphicsContextGLCV.h:
  • platform/graphics/cv/GraphicsContextGLCVANGLE.cpp:
  • platform/graphics/cv/GraphicsContextGLCVANGLE.h:
  • platform/graphics/egl/GLContextEGL.cpp:
  • platform/graphics/egl/GLContextEGL.h:
  • platform/graphics/glx/GLContextGLX.cpp:
  • platform/graphics/glx/GLContextGLX.h:
  • platform/graphics/nicosia/texmap/NicosiaGCGLANGLELayer.h:
  • platform/graphics/opengl/ExtensionsGLOpenGL.cpp:
  • platform/graphics/opengl/ExtensionsGLOpenGLCommon.cpp:
  • platform/graphics/opengl/ExtensionsGLOpenGLES.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGL.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGL.h:
  • platform/graphics/opengl/GraphicsContextGLOpenGLBase.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGLCommon.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGLES.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGLManager.cpp:
  • platform/graphics/opengl/GraphicsContextGLOpenGLPrivate.cpp:
  • platform/graphics/opengl/TemporaryOpenGLSetting.cpp:
  • platform/graphics/opengl/TemporaryOpenGLSetting.h:
  • platform/graphics/texmap/GraphicsContextGLTextureMapper.cpp:
  • platform/graphics/texmap/TextureMapperGCGLPlatformLayer.cpp:
  • platform/graphics/texmap/TextureMapperGCGLPlatformLayer.h:
  • platform/graphics/win/GraphicsContextGLDirect2D.cpp:

Source/WebKit:

  • CMakeLists.txt:
  • UIProcess/API/glib/WebKitProtocolHandler.cpp:

(WebKit::WebKitProtocolHandler::handleGPU):

  • UIProcess/gtk/HardwareAccelerationManager.cpp:

(WebKit::HardwareAccelerationManager::HardwareAccelerationManager):

Source/WTF:

  • wtf/Platform.h:
  • wtf/PlatformEnable.h:
1:25 PM Changeset in webkit [270476] by Andres Gonzalez
  • 4 edits in trunk/Source/WebCore

Prelininary refactoring of TextMarker and TextMarkerRange.
​https://bugs.webkit.org/show_bug.cgi?id=219491

Reviewed by Chris Fleizach.

Covered by existing tests.

TextMarker and TextMarkerRange should become classes on their own right.
As a first step in that direction, this patch moves all the static
functions in WebAccessibilityObjectWrapperMac.mm to make conversions
between TextMarkers and TextMarkerRanges to and from other types to
AXObjectCacheMac.mm.
In addition, removed all ObjectiveC wrappers to these functions and
instead call the functions directly where needed. This is relevant now
with the arrival of isolated tree mode because it saves a non-trivial
call to the wrapper's axBackingObject getter. Furthermore, all the
conversion functions are doing now the appropriate thread check, since
they all need to run on the main thread.
Fixed the handling of the NSAccessibilityMisspellingTextMarkerRangeParameterizedAttribute
request that was calling accessibilityMisspellingSearchCriteriaForParameterizedAttribute
off of the main thread.

  • accessibility/mac/AXObjectCacheMac.mm:

(WebCore::AXObjectCache::postTextStateChangePlatformNotification):
(WebCore::AXTextMarkerRange):
(WebCore::textMarkerRangeFromMarkers):
(WebCore::AXTextMarkerRangeStart):
(WebCore::AXTextMarkerRangeEnd):
(WebCore::getBytesFromAXTextMarker):
(WebCore::accessibilityObjectForTextMarker):
(WebCore::textMarkerForVisiblePosition):
(WebCore::visiblePositionForTextMarker):
(WebCore::textMarkerRangeFromVisiblePositions):
(WebCore::visiblePositionRangeForTextMarkerRange):
(WebCore::textMarkerForCharacterOffset):
(WebCore::characterOffsetForTextMarker):
(WebCore::startOrEndTextMarkerForRange):
(WebCore::textMarkerRangeFromRange):
(WebCore::rangeForTextMarkerRange):

  • accessibility/mac/WebAccessibilityObjectWrapperMac.h:
  • accessibility/mac/WebAccessibilityObjectWrapperMac.mm:

(accessibilityTextOperationForParameterizedAttribute):
(accessibilityMisspellingSearchCriteriaForParameterizedAttribute):
(-[WebAccessibilityObjectWrapper textMarkerForVisiblePosition:]):
(-[WebAccessibilityObjectWrapper textMarkerForFirstPositionInTextControl:]):
(-[WebAccessibilityObjectWrapper doAXAttributedStringForTextMarkerRange:spellCheck:]):
(-[WebAccessibilityObjectWrapper textMarkerRangeFromVisiblePositions:endPosition:]):
(-[WebAccessibilityObjectWrapper textMarkerRangeForSelection]):
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]):
(-[WebAccessibilityObjectWrapper _accessibilitySetValue:forAttribute:]):
(-[WebAccessibilityObjectWrapper _indexForTextMarker:]):
(-[WebAccessibilityObjectWrapper _textMarkerForIndex:]):
(-[WebAccessibilityObjectWrapper debugDescriptionForTextMarker:]):
(-[WebAccessibilityObjectWrapper debugDescriptionForTextMarkerRange:]):
(-[WebAccessibilityObjectWrapper showNodeForTextMarker:]):
(-[WebAccessibilityObjectWrapper showNodeTreeForTextMarker:]):
(-[WebAccessibilityObjectWrapper textMarkerRangeAtTextMarker:forUnit:]):
(-[WebAccessibilityObjectWrapper lineTextMarkerRangeForTextMarker:forUnit:]):
(-[WebAccessibilityObjectWrapper textMarkerForTextMarker:atUnit:]):
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):
(AXTextMarkerRangeStart): MOved to AXObjectCacheMac.mm.
(AXTextMarkerRangeEnd): MOved to AXObjectCacheMac.mm.
(getBytesFromAXTextMarker): MOved to AXObjectCacheMac.mm.
(isTextMarkerIgnored): Deleted.
(-[WebAccessibilityObjectWrapper accessibilityObjectForTextMarker:]): Deleted.
(accessibilityObjectForTextMarker): MOved to AXObjectCacheMac.mm.
(-[WebAccessibilityObjectWrapper textMarkerForCharacterOffset:]): Deleted.
(textMarkerForCharacterOffset): MOved to AXObjectCacheMac.mm.
(-[WebAccessibilityObjectWrapper rangeForTextMarkerRange:]): Deleted.
(characterOffsetForTextMarker): MOved to AXObjectCacheMac.mm.
(-[WebAccessibilityObjectWrapper characterOffsetForTextMarker:]): Deleted.
(visiblePositionForTextMarker): MOved to AXObjectCacheMac.mm.
(visiblePositionRangeForTextMarkerRange): MOved to AXObjectCacheMac.mm.
(-[WebAccessibilityObjectWrapper visiblePositionForTextMarker:]): Deleted.
(-[WebAccessibilityObjectWrapper visiblePositionRangeForTextMarkerRange:]): Deleted.

1:18 PM Changeset in webkit [270475] by Simon Fraser
  • 2 edits in trunk/Source/WebCore

Add ScrollAnimation files to the Xcode project
​https://bugs.webkit.org/show_bug.cgi?id=219566

Reviewed by Yusuke Suzuki.

ScrollAnimation* files were added to Sources.txt but not the Xcode project.

  • WebCore.xcodeproj/project.pbxproj:
10:53 AM Changeset in webkit [270474] by Simon Fraser
  • 14 edits
    2 copies in trunk/Source/WebCore

[LFC Display] Store the display tree as a tree of stacking items
​https://bugs.webkit.org/show_bug.cgi?id=219315

Reviewed by Zalan Bujtas.

Currently the display tree is a full tree, crossing stacking context boundaries, and the
z-order lists are built at paint time.

Change to a tree of StackingItems, where a StackingItem exists for each box that
participates in the z-order sorting algorithm (i.e. boxes that are positioned, or have
styles that create stacking context). Each StackingItem owns the subtree of Display::Boxes
that it paints, and those subtrees are not otherwise connected.

The Display::Tree owns the root StackingItem, and each StackingItem owns its child
StackingItems. The StackingItem tree is built at display tree building time by storing state
in the BuildingState stack. StackingItems are added to the z-order lists of their parent
item at creation time; when done processing boxes for a StackingItem, we then sort its
z-order lists.

Add Box::participatesInZOrderSorting() and a LineBreakBox flag, and call that function
instead of the version on Display::Style to work around webkit.org/b/219335 for now.

  • Sources.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • display/DisplayLayerController.cpp:
  • display/DisplayTree.cpp:

(WebCore::Display::Tree::Tree):
(WebCore::Display::Tree::rootBox const):

  • display/DisplayTree.h:

(WebCore::Display::Tree::rootStackingItem const):
(WebCore::Display::Tree::rootBox const): Deleted.

  • display/DisplayTreeBuilder.cpp:

(WebCore::Display::TreeBuilder::build):
(WebCore::Display::TreeBuilder::pushStateForBoxDescendants):
(WebCore::Display::TreeBuilder::popState):
(WebCore::Display::TreeBuilder::insertIntoTree):
(WebCore::Display::TreeBuilder::buildInlineDisplayTree):
(WebCore::Display::TreeBuilder::recursiveBuildDisplayTree):
(WebCore::Display::outputDisplayBox):
(WebCore::Display::outputDisplayTree):
(WebCore::Display::displayTreeAsText):
(WebCore::Display::outputStackingTree):
(WebCore::Display::showDisplayTree):

  • display/DisplayTreeBuilder.h:
  • display/css/DisplayBox.cpp:

(WebCore::Display::Box::participatesInZOrderSorting const):

  • display/css/DisplayBox.h:

(WebCore::Display::Box::isLineBreakBox const):

  • display/css/DisplayBoxFactory.cpp:

(WebCore::Display::BoxFactory::displayBoxForRootBox const):
(WebCore::Display::BoxFactory::displayBoxForLayoutBox const):
(WebCore::Display::BoxFactory::setupBoxModelBox const):

  • display/css/DisplayBoxFactory.h:
  • display/css/DisplayCSSPainter.cpp:

(WebCore::Display::CSSPainter::recursivePaintDescendantsForPhase):
(WebCore::Display::CSSPainter::paintAtomicallyPaintedBox):
(WebCore::Display::CSSPainter::paintStackingContext):
(WebCore::Display::CSSPainter::paintTree):
(WebCore::Display::CSSPainter::isStackingContextPaintingBoundary): Deleted.
(WebCore::Display::CSSPainter::participatesInZOrderSorting): Deleted.
(WebCore::Display::CSSPainter::collectStackingContextDescendants): Deleted.
(WebCore::Display::CSSPainter::recursiveCollectLayers): Deleted.

  • display/css/DisplayCSSPainter.h:
6:23 AM Changeset in webkit [270473] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][IFC] Create an inline box for </span> when it's the first box on the line
​https://bugs.webkit.org/show_bug.cgi?id=219556

Reviewed by Antti Koivisto.

When the line starts with inline-box-end (</span>), we need to create an inline box for that box itself
and for its ancestors as well.

This fixes css1/units/rounding.html with ALLOW_INLINES enabled.

  • layout/inlineformatting/InlineFormattingContextGeometry.cpp:

(WebCore::Layout::LineBoxBuilder::constructInlineLevelBoxes):

6:21 AM Changeset in webkit [270472] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][Integration] Do not construct a new layout box for every inline box end (InlineWalker)
​https://bugs.webkit.org/show_bug.cgi?id=219557

Reviewed by Antti Koivisto.

We use the InlineWalker to walk the inline part of the render tree to build the corresponding layout (sub)tree.

With content e.g <span>text</span>, InlineWalker visits

  1. <span> (RenderInline)
  2. text (RenderText)
  3. </span> (RenderInline)

This patch ensures that we don't create yet another layout box for step #3.

  • layout/integration/LayoutIntegrationBoxTree.cpp:

(WebCore::LayoutIntegration::BoxTree::buildTree):

3:54 AM Changeset in webkit [270471] by Diego Pino Garcia
  • 2 edits in trunk/LayoutTests

[GTK] Unreviewed test gardening. Gardened more media-source timeouts.

  • platform/gtk/TestExpectations:
Note: See TracTimeline for information about the timeline view.