Timeline
May 12, 2019:
- 11:51 PM Changeset in webkit [245232] by
-
- 2 edits in branches/safari-608.1.24-branch/Source/WebCore
Cherry-pick r245197. rdar://problem/50628434
Downgrade RELEASE_ASSERT TO RELEASE_LOG_FAULT for SQLite Class A files
https://bugs.webkit.org/show_bug.cgi?id=197760
Reviewed by Jer Noble.
We have all the data we need, and this crash is happening more than
expected.
- platform/sql/SQLiteDatabase.cpp: (WebCore::SQLiteDatabase::open):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245197 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245231] by
-
- 2 edits in branches/safari-608.1.24-branch/Source/WebKit
Cherry-pick r245195. rdar://problem/46548586
Returning incorrect marked text rects
https://bugs.webkit.org/show_bug.cgi?id=197758
<rdar://problem/46548586>
Reviewed by Tim Horton.
We are not returning marked text rects in the correct view coordinate space.
This is the same translation we are applying to the caret rects.
- WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245230] by
-
- 3 edits2 adds in branches/safari-608.1.24-branch
Cherry-pick r245191. rdar://problem/48027412
[iOS] baidu.com: Synthetic bold renders too far apart, appears doubled.
https://bugs.webkit.org/show_bug.cgi?id=197781
<rdar://problem/48027412>
Reviewed by Simon Fraser.
Source/WebCore:
Synthetic bold is essentially two regular glyphs painted with an offset. While on macOS this offset is always 1px (CSS), on iOS larger font produces higher offset value. At paint time, this offset value (in CSS px unit) get converted
to a device pixel value taking context scale into account. This conversion ensures that the gap between the 2 regular glyphs won't get wider (in device pixels) as the user pinch zooms in.
This works as long as the scale on the context is >= 1. This patch ensures that a scaled down context won't blow up this gap.
Test: fast/text/large-synthetic-bold-with-scale-transform.html
- platform/graphics/cocoa/FontCascadeCocoa.mm: (WebCore::FontCascade::drawGlyphs):
LayoutTests:
- fast/text/large-synthetic-bold-with-scale-transform-expected.html: Added.
- fast/text/large-synthetic-bold-with-scale-transform.html: Added.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245191 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245229] by
-
- 5 edits in branches/safari-608.1.24-branch/Source/WebKit
Cherry-pick r245189. rdar://problem/50646747
Let WebKit clients supply an application name for user agent in modern compatibility mode
https://bugs.webkit.org/show_bug.cgi?id=197782
<rdar://problem/50646747>
Reviewed by Beth Dakin.
Add plumbing for a new private property on WKWebpagePreferences.
- UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::copy const):
- UIProcess/API/APIWebsitePolicies.h:
- UIProcess/API/Cocoa/WKWebpagePreferences.mm: (-[WKWebpagePreferences _applicationNameForUserAgentWithModernCompatibility]): (-[WKWebpagePreferences _setApplicationNameForUserAgentWithModernCompatibility:]):
- UIProcess/API/Cocoa/WKWebpagePreferencesPrivate.h:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245189 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245228] by
-
- 17 edits in branches/safari-608.1.24-branch/Source
Cherry-pick r245183. rdar://problem/50065100
Add WKWebViewConfiguration._canShowWhileLocked SPI
https://bugs.webkit.org/show_bug.cgi?id=197777
<rdar://problem/50065100>
Reviewed by Tim Horton.
Source/WebCore/PAL:
- pal/spi/cocoa/QuartzCoreSPI.h:
Source/WebKit:
- Platform/mac/LayerHostingContext.h:
- Platform/mac/LayerHostingContext.mm: (WebKit::LayerHostingContext::createForExternalHostingProcess):
- Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode):
- Shared/WebPageCreationParameters.h:
- UIProcess/API/APIPageConfiguration.cpp: (API::PageConfiguration::copy const):
- UIProcess/API/APIPageConfiguration.h: (API::PageConfiguration::canShowWhileLocked const): (API::PageConfiguration::setCanShowWhileLocked):
- UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration _setCanShowWhileLocked:]): (-[WKWebViewConfiguration _canShowWhileLocked]):
- UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:
- UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters):
- WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemoteCustom.mm: (WebKit::PlatformCALayerRemoteCustom::PlatformCALayerRemoteCustom):
- WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.h:
- WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.mm: (WebKit::RemoteLayerTreeContext::canShowWhileLocked const):
- WebProcess/WebPage/WebPage.cpp: (WebKit::m_canShowWhileLocked): (WebKit::m_shrinkToFitContentTimer): Deleted.
- WebProcess/WebPage/WebPage.h: (WebKit::WebPage::canShowWhileLocked const):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245227] by
-
- 3 edits in branches/safari-608.1.24-branch/Source/WebKit
Cherry-pick r245153. rdar://problem/50604700
Guard long press link preview with a USE macro rather than complicated includes
https://bugs.webkit.org/show_bug.cgi?id=197728
<rdar://problem/50604700>
Reviewed by Wenson Hsieh.
It was getting complicated to manage the coordination between WebKitAdditions
and WebKit without having to split up the includes into multiple files
or have lots of duplication.
Instead, WebKitAdditions will now define a USE macro which can be used
in various places through WebKit.
- UIProcess/ios/WKContentViewInteraction.h:
- UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dragInteraction:itemsForBeginningSession:]): (-[WKContentView _contentsOfUserInterfaceItem:]): (previewIdentifierForElementAction): (-[WKContentView shouldUsePreviewForLongPress]): (-[WKContentView _registerPreview]): (-[WKContentView _unregisterPreview]): (shouldUsePreviewForLongPress): Deleted. (-[WKContentView _registerPreviewLongPress]): Deleted. (-[WKContentView _unregisterPreviewLongPress]): Deleted.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245153 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245226] by
-
- 2 edits in branches/safari-608.1.24-branch/Source/WebKit
Cherry-pick r245148. rdar://problem/50457731
REGRESSION (r241734): 1% slower PLT on iPad
https://bugs.webkit.org/show_bug.cgi?id=197745
<rdar://problem/50457731>
Reviewed by Per Arne Vollan.
For now, only create a keyboard when WKContentView becomes first responder if a hardware keyboard
is attached or an editable element is focused to recover the 1% loss when a keyboard is not attached.
We can do better and by that I mean be lazier. We'll do this <https://bugs.webkit.org/show_bug.cgi?id=197746>.
In r241734 we unified the key event handling code paths so we use exactly one for both software and
hardware key events. We took a simple approach of always requesting UIKit to create a keyboard when
the WKContentView becomes first responder. We did this so that we could continue listening for hardware
key events even when a non-editable element is focused and dispatch DOM events. As it turns out, always
creating a keyboard is expensive and caused a ~1% slowdown in page load time on iPad.
- UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _requiresKeyboardWhenFirstResponder]): Only create a keyboard if a hardware keyboard is attached or an editable element is focused. (-[WKContentView _hardwareKeyboardAvailabilityChanged]): Reload all input view (this will cause keyboard creation) if -_requiresKeyboardWhenFirstResponder returns YES.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:51 PM Changeset in webkit [245225] by
-
- 8 edits4 adds in branches/safari-608.1.24-branch
Cherry-pick r245144. rdar://problem/47902054
[iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
https://bugs.webkit.org/show_bug.cgi?id=197632
<rdar://problem/47902054>
Reviewed by Brent Fulgham.
Source/WebKit:
Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
opens a new window.
By default we only allow popups to open if they were user initiated (like when a person clicks
on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
WebCore processes an event from WebKit. So long as this token is on the stack we consider
all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
to determine if it's being called by the keyboard. If it is then we can assume that this is
part of key event handling and hence was initiated by the user. We can pass along this detail
to the WebProcess for it to push a new UserGestureToken onto the stack.
For now we only track whether text inserted by the keyboard was user initiated or not. In
<https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
- Platform/spi/ios/UIKitSPI.h: Expose SPI.
- Shared/Cocoa/InsertTextOptions.cpp: (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode): (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode): Encode and decode whether we are processing a user gesture.
- Shared/Cocoa/InsertTextOptions.h:
- UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or the embedding client did. We only want to privilege user initiated actions (the keyboard).
- WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized depending on whether we are or are not processing a user gesture.
LayoutTests:
Add tests to ensure we fire input and keypress events in the correct order and that we can
submit a <form> with target = "_blank" using the Return key.
- fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
- fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
- fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
- fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
- platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added in <rdar://problem/50596032>.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 11:30 PM Changeset in webkit [245224] by
-
- 7 edits in branches/safari-608.1.24-branch/Source
Versioning.
- 11:15 PM Changeset in webkit [245223] by
-
- 7 edits in tags/Safari-608.1.23.1/Source
Versioning.
- 11:07 PM Changeset in webkit [245222] by
-
- 1 copy in tags/Safari-608.1.23.1
Tag Safari-608.1.23.1.
- 9:13 PM Changeset in webkit [245221] by
-
- 2 edits in trunk/LayoutTests
REGRESSION (r245208): compositing/shared-backing/sharing-bounds-non-clipping-shared-layer.html asserts
https://bugs.webkit.org/show_bug.cgi?id=197818
Approved by Jon Lee.
Skip this test until a fix for bug 197818 lands.
- platform/ios-wk2/TestExpectations:
- 8:57 PM Changeset in webkit [245220] by
-
- 3 edits2 adds in trunk
When the set of backing-sharing layers changes, we need to issue a repaint
https://bugs.webkit.org/show_bug.cgi?id=197825
Reviewed by Zalan Bujtas.
Source/WebCore:
If the set of layers painting into a shared backing store changes, we need
to repaint that backing store. This happens when scrolling as shared layers
enter the visible area.
Test: compositing/shared-backing/overflow-scroll/repaint-shared-on-scroll.html
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::setBackingSharingLayers):
LayoutTests:
- compositing/shared-backing/overflow-scroll/repaint-shared-on-scroll-expected.html: Added.
- compositing/shared-backing/overflow-scroll/repaint-shared-on-scroll.html: Added.
- 8:07 PM Changeset in webkit [245219] by
-
- 6 edits in trunk/Source/WebCore
Add logging for RenderLayer clip rects
https://bugs.webkit.org/show_bug.cgi?id=197547
Reviewed by Zalan Bujtas.
Add a ClipRects log channel, and stream output for ClipRect and ClipRects.
The ClipRect code is performance sensitive, even in debug, so guard the log sites
with clipRectsLogEnabled() because the macro still evaluates its arguments even if
the channel is disabled (we need some better way to log that doesn't do this).
- platform/Logging.h:
- rendering/ClipRect.cpp:
(WebCore::operator<<):
- rendering/ClipRect.h:
- rendering/RenderLayer.cpp:
(WebCore::operator<<):
(WebCore::RenderLayer::calculateClipRects const):
- rendering/RenderLayer.h:
- 8:01 PM Changeset in webkit [245218] by
-
- 4 edits in trunk/Source/WebCore
Refactor composited backing-sharing code
https://bugs.webkit.org/show_bug.cgi?id=197824
Reviewed by Zalan Bujtas.
Clean up the backing-sharing code to share more code, and make it easier to understand.
Moves more logic into member functions on BackingSharingState, which are named to make
their functions clearer: startBackingSharingSequence/endBackingSharingSequence.
computeCompositingRequirements() and traverseUnchangedSubtree() now just call
updateBeforeDescendantTraversal/updateAfterDescendantTraversal.
No behavior change.
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::willBeDestroyed):
(WebCore::RenderLayerBacking::setBackingSharingLayers): Remove the early return, since
we need to call setBackingProviderLayer() on the sharing layers in both code paths.
(WebCore::RenderLayerBacking::removeBackingSharingLayer):
(WebCore::RenderLayerBacking::clearBackingSharingLayers):
- rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::BackingSharingState::backingProviderCandidate const):
(WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer):
(WebCore::RenderLayerCompositor::BackingSharingState::startBackingSharingSequence):
(WebCore::RenderLayerCompositor::BackingSharingState::endBackingSharingSequence):
(WebCore::RenderLayerCompositor::BackingSharingState::updateBeforeDescendantTraversal):
(WebCore::RenderLayerCompositor::BackingSharingState::updateAfterDescendantTraversal):
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
(WebCore::RenderLayerCompositor::traverseUnchangedSubtree):
(WebCore::RenderLayerCompositor::BackingSharingState::resetBackingProviderCandidate): Deleted.
- rendering/RenderLayerCompositor.h:
- 7:57 PM Changeset in webkit [245217] by
-
- 2 edits in trunk/Source/WebCore
Use clampTo in AVVideoCaptureSource::setSizeAndFrameRateWithPreset
https://bugs.webkit.org/show_bug.cgi?id=197704
Reviewed by Alex Christensen.
Use clampTo as suggested in bug 196214 review.
No change of behavior.
- platform/mediastream/mac/AVVideoCaptureSource.mm:
(WebCore::AVVideoCaptureSource::setSizeAndFrameRateWithPreset):
- 7:56 PM Changeset in webkit [245216] by
-
- 2 edits in trunk/Source/WebCore
Use the main screen for screen capture
https://bugs.webkit.org/show_bug.cgi?id=197804
<rdar://problem/47671383>
Reviewed by Eric Carlson.
If the main screen, i.e. the screen that has focus at the time of
selection of the screen to capture, is capturable, add it to the list
of screen devices, but do not add any other screen.
This will make sure the main screen is selected.
Manually tested.
- platform/mediastream/mac/ScreenDisplayCaptureSourceMac.mm:
(WebCore::ScreenDisplayCaptureSourceMac::screenCaptureDevices):
- 4:05 PM Changeset in webkit [245215] by
-
- 8 edits4 adds in trunk
[Curl] Suppress extra didReceiveAuthenticationChallenge call when accessing a server which checks basic auth.
https://bugs.webkit.org/show_bug.cgi?id=197650
Patch by Takashi Komori <Takashi.Komori@sony.com> on 2019-05-12
Reviewed by Fujii Hironori.
Source/WebCore:
When Curl port accesses a page which checks Basic Authentication credential and server trust challenge occurs,
Curl port calls extra didReceiveAuthenticationChallenge unnecessarily.
This is because Curl port discards information about allowed server trust challenge before in NetworkDataTaskCurl::restartWithCredential.
Test: http/tests/ssl/curl/certificate-and-authentication.html
- platform/network/curl/CurlRequest.h:
(WebCore::CurlRequest::isServerTrustEvaluationDisabled):
Source/WebKit:
- NetworkProcess/curl/NetworkDataTaskCurl.cpp:
(WebKit::NetworkDataTaskCurl::restartWithCredential):
LayoutTests:
- TestExpectations:
- http/tests/resources/basic-auth.php: Added.
- http/tests/ssl/curl/certificate-and-authentication-expected.txt: Added.
- http/tests/ssl/curl/certificate-and-authentication.html: Added.
- platform/wincairo-wk1/TestExpectations:
- platform/wincairo/TestExpectations:
- 3:50 PM Changeset in webkit [245214] by
-
- 33 edits5 adds in trunk
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
- Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor. Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
- We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
- We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- Sources.txt:
- bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
- bytecode/CodeBlockJettisoningWatchpoint.h:
- bytecode/CodeOrigin.h:
- bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
- bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
- bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
- bytecode/StructureStubClearingWatchpoint.h:
- bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
- bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
- dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
- dfg/DFGAdaptiveStructureWatchpoint.h:
- heap/PackedCellPtr.h: Added.
- runtime/FunctionRareData.h:
- runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
- runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
- runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
- runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
- Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
- We cannot take reference / pointer to the underlying storage since they are unaligned.
- Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
- WTF.xcodeproj/project.pbxproj:
- wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
- wtf/CMakeLists.txt:
- wtf/DumbPtrTraits.h:
- wtf/DumbValueTraits.h:
- wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
- wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
- wtf/Platform.h:
- wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
- wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
- wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
- TestWebKitAPI/CMakeLists.txt:
- TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
- TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
- TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
- 12:43 PM Changeset in webkit [245213] by
-
- 9 edits1 add in trunk/Source/JavaScriptCore
[JSC] Compact generator code's bytecode size
https://bugs.webkit.org/show_bug.cgi?id=197822
Reviewed by Michael Saboff.
op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
It makes all generator's op_put_to_scope wide bytecode.
In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
- bytecode/BytecodeList.rb:
- bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
- bytecode/Fits.h:
- bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitProfileType):
(JSC::BytecodeGenerator::emitPutToScope):
(JSC::BytecodeGenerator::localScopeDepth const):
- bytecompiler/BytecodeGenerator.h:
- runtime/SymbolTableOrScopeDepth.h: Added.
(JSC::SymbolTableOrScopeDepth::symbolTable):
(JSC::SymbolTableOrScopeDepth::scopeDepth):
(JSC::SymbolTableOrScopeDepth::raw):
(JSC::SymbolTableOrScopeDepth::symbolTable const):
(JSC::SymbolTableOrScopeDepth::scopeDepth const):
(JSC::SymbolTableOrScopeDepth::raw const):
(JSC::SymbolTableOrScopeDepth::dump const):
(JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):
May 11, 2019:
- 4:17 PM Changeset in webkit [245212] by
-
- 6 edits3 adds in trunk
Overflow scroll that becomes non-scrollable should stop being composited
https://bugs.webkit.org/show_bug.cgi?id=197817
<rdar://problem/50697290>
Reviewed by Antti Koivisto.
Source/WebCore:
Remove the iOS-specific #ifdef around code that triggers a compositing re-evaluation
when scrolling state changes.
Test: compositing/scrolling/async-overflow-scrolling/become-non-scrollable.html
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateScrollInfoAfterLayout):
LayoutTests:
Put in a compositing/scrolling/async-overflow-scrolling dir so we can enable it only
for platforms that have async overflow scrolling.
- TestExpectations:
- compositing/scrolling/async-overflow-scrolling/become-non-scrollable-expected.txt: Added.
- compositing/scrolling/async-overflow-scrolling/become-non-scrollable.html: Added.
- platform/ios-wk2/TestExpectations:
- platform/mac-wk2/TestExpectations:
- 4:14 PM Changeset in webkit [245211] by
-
- 2 edits in trunk/LayoutTests
Cleaning up results for legacy-animation-engine tests
Two tests were fixed in bug 188357.
The third one is still broken, and we have bug 184611 tracking it.
- platform/mac-wk1/TestExpectations:
- 4:02 PM Changeset in webkit [245210] by
-
- 2 edits in trunk/LayoutTests
Removing flaky expectation for fast/repaint/canvas-object-fit.html
https://bugs.webkit.org/show_bug.cgi?id=188910
- platform/mac-wk1/TestExpectations:
- 3:29 PM Changeset in webkit [245209] by
-
- 2 edits in trunk/LayoutTests
Removing flaky expectation for fast/animation/request-animation-frame.html
https://bugs.webkit.org/show_bug.cgi?id=190888
- platform/ios-wk2/TestExpectations:
- 3:22 PM Changeset in webkit [245208] by
-
- 3 edits8 adds in trunk
Layer bounds are incorrect for sharing layers that paint with transforms
https://bugs.webkit.org/show_bug.cgi?id=197768
<rdar://problem/50695493>
Reviewed by Zalan Bujtas.
Source/WebCore:
We don't need to traverse shared layers if the backing-provider has overflow clip,
because we know they are containing-block descendants and therefore clipped.
Note tha the CSS "clip" property doesn't guarantee this, because the clip rect
can be larger than the element, so in that case we just traverse shared layers.
Tests: compositing/shared-backing/sharing-bounds-clip.html
compositing/shared-backing/sharing-bounds-non-clipping-shared-layer.html
compositing/shared-backing/sharing-bounds-transformed-sharing-layer.html
compositing/shared-backing/sharing-bounds.html
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateCompositedBounds):
LayoutTests:
Tests for backing-shared layer bounds in various configurations.
- compositing/shared-backing/sharing-bounds-clip-expected.txt: Added.
- compositing/shared-backing/sharing-bounds-clip.html: Added.
- compositing/shared-backing/sharing-bounds-expected.txt: Added.
- compositing/shared-backing/sharing-bounds-non-clipping-shared-layer-expected.txt: Added.
- compositing/shared-backing/sharing-bounds-non-clipping-shared-layer.html: Added.
- compositing/shared-backing/sharing-bounds-transformed-sharing-layer-expected.txt: Added.
- compositing/shared-backing/sharing-bounds-transformed-sharing-layer.html: Added.
- compositing/shared-backing/sharing-bounds.html: Added.
- 3:05 PM Changeset in webkit [245207] by
-
- 4 edits2 adds in trunk
Translucent gradient rendering bug due to will-change transform
https://bugs.webkit.org/show_bug.cgi?id=197654
<rdar://problem/50547664>
Reviewed by Dean Jackson.
Source/WebCore:
We failed to re-evaluate 'contentsOpaque' when a background changed, because this
happened in updateGeometry() and that doesn't run for background changes.
However, 'contentsOpaque' also requires knowing about geometry because we have to
turn it off when there's subpixel positioning, and updateConfiguration()
runs before updateGeometry().
So compute m_hasSubpixelRounding in updateGeometry() and set contentsOpaque in
updateAfterDescendants().
Test: compositing/contents-opaque/background-change-to-transparent.html
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateConfiguration):
(WebCore::RenderLayerBacking::updateGeometry):
(WebCore::RenderLayerBacking::updateAfterDescendants):
- rendering/RenderLayerBacking.h:
LayoutTests:
- compositing/contents-opaque/background-change-to-transparent-expected.txt: Added.
- compositing/contents-opaque/background-change-to-transparent.html: Added.
- 1:58 PM Changeset in webkit [245206] by
-
- 3 edits2 adds in trunk
When the scroller hosting a shared layer becomes non-scrollable, content disappears
https://bugs.webkit.org/show_bug.cgi?id=197766
<rdar://problem/50695808>
Reviewed by Zalan Bujtas.
Source/WebCore:
RenderLayerCompositor::requiresOwnBackingStore() should return true for a layer that shares
its backing store. We always made backing for overlap layers, so even if the sharing layers
have no painted content, this should rarely be a backing store memory regression.
Test: compositing/shared-backing/overflow-scroll/sharing-layer-becomes-non-scrollable.html
- rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresOwnBackingStore const):
LayoutTests:
- compositing/shared-backing/overflow-scroll/sharing-layer-becomes-non-scrollable-expected.html: Added.
- compositing/shared-backing/overflow-scroll/sharing-layer-becomes-non-scrollable.html: Added.
- 10:35 AM Changeset in webkit [245205] by
-
- 6 edits14 adds in trunk
Backing-sharing layers with transforms render incorrectly
https://bugs.webkit.org/show_bug.cgi?id=197692
<rdar://problem/50652127>
Reviewed by Antti Koivisto.
Source/WebCore:
Layers that paint into shared backing need to enter the RenderLayer painting code
in a way that paints the filters, transforms, opacity and blending.
RenderLayerBacking::paintIntoLayer() normally enters at paintLayerContents(), because
the effects are rendered via the GraphicsLayer, but shared layers will paint effects.
Note that if the backing-provider has effects, it will be the stacking context
for the shared layers, so it's correct that sharing layers are impacted by effects
on the backing-provider.
In addition, we have to ensure that we don't over-eagerly make layers shared.
Consider:
<div class="clipping">
<div class="sharing">
<div class="inner">
</div>
</div>
</div>
Here "clipping" is the provider layer, "sharing" paints into shared backing, but
we don't want to also mark "inner" as sharing, since "sharing" will just paint it.
This is akin to avoiding unnecessary compositing of z-order descendants when they can just
paint.
To do this we need to ensure that sharing layers are treated like compositing layers
in the overlap map, i.e. when a layer is sharing, we call overlapMap.pushCompositingContainer(),
and later overlapMap.popCompositingContainer().
Tests: compositing/shared-backing/nested-shared-layers-with-opacity.html
compositing/shared-backing/shared-layer-has-blending.html
compositing/shared-backing/shared-layer-has-filter.html
compositing/shared-backing/shared-layer-has-opacity.html
compositing/shared-backing/shared-layer-has-reflection.html
compositing/shared-backing/shared-layer-has-transform.html
compositing/shared-backing/shared-layer-isolates-blending.html
compositing/shared-backing/shared-transformed-layer-bounds.html
compositing/shared-backing/sharing-layer-becomes-non-scrollable.html
compositing/shared-backing/sharing-layer-has-effect.html
- rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintLayer):
(WebCore::RenderLayer::paintLayerWithEffects):
- rendering/RenderLayer.h:
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::paintIntoLayer):
- rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::CompositingState::stateForPaintOrderChildren const):
(WebCore::backingProviderLayerCanIncludeLayer):
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
(WebCore::RenderLayerCompositor::traverseUnchangedSubtree):
LayoutTests:
Ref tests for effects on sharing layers. The references make "clipping" be stacking context via z-index,
which eliminates sharing.
- compositing/shared-backing/nested-shared-layers-with-opacity-expected.html: Added.
- compositing/shared-backing/nested-shared-layers-with-opacity.html: Added.
- compositing/shared-backing/shared-layer-has-blending-expected.html: Added.
- compositing/shared-backing/shared-layer-has-blending.html: Added.
- compositing/shared-backing/shared-layer-has-filter-expected.html: Added.
- compositing/shared-backing/shared-layer-has-filter.html: Added.
- compositing/shared-backing/shared-layer-has-opacity-expected.html: Added.
- compositing/shared-backing/shared-layer-has-opacity.html: Added.
- compositing/shared-backing/shared-layer-has-reflection-expected.html: Added.
- compositing/shared-backing/shared-layer-has-reflection.html: Added.
- compositing/shared-backing/shared-layer-has-transform-expected.html: Added.
- compositing/shared-backing/shared-layer-has-transform.html: Added.
- compositing/shared-backing/shared-layer-isolates-blending-expected.html: Added.
- compositing/shared-backing/shared-layer-isolates-blending.html: Added.
