Re: [webkit-dev] Request for position: Canvas 2D display-p3 support

[Sam Weinig via webkit-dev]

Hi Christopher,

We are in favor of this proposal.

- Sam

> On Jun 9, 2021, at 6:39 PM, Christopher Cameron via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> (and sorry for the duplicate post here, I mangled the headers on the previous 
> post!)
> 
> This is a request for WebKit's position on display-p3 support for Canvas 2D. 
> This is already being tracked in bugs.webkit.org  
> here .
> 
> Summary:
> 
> Adds a color space parameter to CanvasRenderingContext2DSettings, which 
> defaults to "srgb" and can take on the value of "display-p3". Adds 
> ImageDataSettings, which allows specifying a color space parameter to 
> getImageData/createImageData and related constructors.
> 
> Spec:
> 
> WhatWG spec changes merged in this PR 
> .
> 
> Tests:
> 
> https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
>  
> 
> Includes tests of ImageData (get and put), and ensuring no loss when doing 
> toBlob and toDataURL round-trips.
> 
> Thank you for your feedback!
> 
> Christopher
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: preferCurrentTab

[Sam Weinig via webkit-dev]

Hi Elad,

Are there other existing uses of the term “tab” in other web exposed APIs? It 
feels a bit wrong to be wrong to be encoding that specific UI treatment into 
API.

- Sam

> On Jun 9, 2021, at 4:20 AM, Elad Alon via webkit-dev 
>  wrote:
> 
> This is a request for WebKit's position on adding a dictionary member in 
> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set to 
> true, the user agent will display the current tab as the most prominent 
> option in the media-picker which getDisplayMedia invokes.
> 
> Links:
> Explainer 
> 
> Spec 
> ChromeStatus 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

[Sam Weinig via webkit-dev]

Hi Jer,

I think it sounds like a reasonable rule to allow Swift for bridging purposes 
only, with the caveat that we should prefer Objective-C/C where it can be used.

The one other place that Swift seems reasonable for WebKit is in the definition 
and refinement of Swift bindings to WebKit’s public API.

That is to say, for the time being, we should avoid Swift in tools and core 
functionality.

Thanks for bringing this up on the list.

- Sam

> On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
>  wrote:
> 
> Hi all!
> 
> We're working on some new features that currently use APIs exposed through 
> Swift. We have not yet approved writing and committing WebKit code in Swift, 
> given runtime, library, and just plain mental overhead that comes with adding 
> a new language to the project. But I'd argue that doing so for the purpose of 
> allowing existing C++ code to call into Swift APIs is probably not terrible.
> 
> Should we relax our "no new language" policy, only for the purposes of 
> allowing our core language code to call into APIs in Swift?
> 
> (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
> 
> Thanks, and look forward to hearing from everyone,
> 
> -Jer
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Is anyone building with USE(DIRECT2D)?

[Sam Weinig via webkit-dev]

Hi WebKit-dev,

Is anyone still using attempting to build using USE(DIRECT2D) enabled? 
Recently, I updated files to “keep” it working, but in some I have seen things 
that obviously wouldn’t compile and think it is probably unmaintained. 

So is anyone using it?

- Sam


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Sam Weinig via webkit-dev]

Hi,

I am curious about the current state of our knowledge about the various 
benefits we are gaining from Unified Source. I think it is important to 
reevaluate it from time to time to ensure we are still getting the benefits we 
want (as there are some not so insignificant downsides). I know when it was 
introduced, it was a win for clean builds but I don’t believe there have been 
any recent measurements.

So, does anyone have any recent measurements of clean build times with and 
without unified sources enabled? If so, what is the current delta?

- Sam

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

[Sam Weinig via webkit-dev]

Hey Geoff and Chris,

> On Dec 1, 2020, at 9:21 AM, Geoff Garen via webkit-dev 
>  wrote:
> 
> A few thoughts here:
> 
> 1. It’s not just ref counting. 
> 
> To make String thread-safe, you also need to address all other data members. 
> That means all state in m_hashAndFlags, including the 8bit/16bit state.
> 
> It appears that your testing strategy did not reveal this point so far; so, 
> you probably need to expand your plan for unit testing concurrent access to a 
> string, with a focus on writing tests that fail with the current 
> implementation.
> 
> 2. Performance is a challenge.
> 
> I’ve tested making String thread-safe pretty extensively. On modern Apple 
> Silicon, it’s free. But on Intel chips, it’s very expensive.

First of all, crazy!

> 
> Because it’s so expensive, and because we have a no regression policy for 
> performance, I don’t think there’s a way to land this change in pieces. It 
> has to be a mega-patch, so we can test its performance as a whole.

Were you able to quantify anything additional about the performance regression 
on Intel, for instance, if there were any types of String usage that were 
particularly hard hit? If not (or you haven’t tried), do you think there are 
any metrics we should look into gathering that might help pin point where 
things could maybe be optimized? Ideally we would be able to identify places 
where we unnecessarily ref-deref StringImpls where either a move or judicious 
use of StringView would work just as well. 

The Blink document (linked in the bugzilla bug) suggests they identified some 
mitigations, but I am not clear they will be representative for us today.

Putting on my old bindings hat, one area that might be able to get some wins 
here is how Strings (and other ref counted things, but let’s stay focused) are 
passed from the JS bindings layer to the DOM. In most cases Strings should be 
able to be moved into the DOM without refcount churn, but since many of our 
functions take `const String&` or `const AtomString&` we lose out.

- Sam

> 
> 3. I’m surprised by the premise that thread-safe String is a requirement for 
> FontCache and/or the GPU Process.
> 
> It’s certainly a false premise that there’s consensus on this premise, since 
> I do not agree.
> 
> Can you share some problem statements regarding FontCache and/or the GPU 
> Process that explain the problem we’re trying to solve?
> 
> Thanks,
> Geoff
> 
>> On Dec 1, 2020, at 9:09 AM, Chris Lord via webkit-dev 
>>  wrote:
>> 
>> Hi all,
>> 
>> As part of the work for making FontCache thread-safe, it's necessary for
>> there to be a thread-safe AtomString. After discussion, it seems that a
>> thread-safe StringImpl is generally desirable and GPUProcess also has a
>> need of it. I've filed a bug to track this work:
>> https://bugs.webkit.org/show_bug.cgi?id=219285
>> 
>> Google have already done this for Blink and there's a nice plan and lots
>> of discussion to read. Their plan document is linked in the bug. I think
>> we'd be well-served by taking broadly the same approach, which is to
>> make ref-counting on StringImpl atomic and to guard AtomStringTable
>> access with a lock.
>> 
>> Making String thread-safe has implications, of course, and I'd like to
>> open discussion on this - Making ref-counting atomic on StringImpl has a
>> significant, negative impact on the expense of ref and deref operations.
>> I'm interested in discussing how we should approach this in terms of
>> tracking the work in Bugzilla and how to go about landing it. Perhaps
>> people also have alternative ideas?
>> 
>> On the bug is a first-run at implementing the above approach, currently
>> minus the follow-up of everywhere taking into consideration that
>> String/AtomString are now thread-safe. The impact on StringImpl
>> ref/deref performance has it running on my Xeon desktop machine at about
>> 30-50% of non-atomic ref/deref performance. Speedometer 2.0 takes a 1-8%
>> hit considering error margins, but I'm fairly certain it's mostly on the
>> higher end of that and I've not run enough iterations just yet.
>> Jetstream 1.1 seems practically unaffected, I can't run 2.0 with or
>> without the patch, it appears to hang the browser on the bomb-workers
>> test (at least if it completes, it's not in a reasonable time-frame). I
>> would guess that results may vary wildly depending on platform and
>> available atomic access primitives. As one might expect, the impact is
>> far less on a debug build.
>> 
>> I think the initial patch of making it thread-safe vs. the follow-up of
>> altering various areas to take it into account could/should be split,
>> but I assume we'd want to land them at the same time. This is cumbersome
>> with how WebKit Bugzilla currently works and I'd like to hear what
>> people think and how similar changes have been made in the past.
>> 
>> Thoughts?
>> 
>> Regards,
>> 
>> Chris
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org