Re: [webkit-dev] Suggesting to enable paint timing by default

2020-05-11 Thread Noam Rosenthal
On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak  wrote:

>
> I noticed from comments in one of the Radars that the patch may result in
> an additional “fake paint”, so it should probably be performance tested.
> Have you done any testing?
>
I've tested it locally, I haven't noticed any significant side effect,
because in complex situations the fake paint only happens once per page and
bails early once contentfulness is detected. but I can run any additional
test needed.


> We’ll likely want to A/B some of Apple’s page load speed benchmarks.
>
A/B testing load speed sounds sensible. How do we go about doing that?


>
> I’d like to hear from others on maturity of the spec and readiness of the
> code.
>

>  - Maciej
>
> On May 11, 2020, at 11:44 AM, Noam Rosenthal  wrote:
>
> Following the discussion with Simon in
> https://bugs.webkit.org/show_bug.cgi?id=78011
>
> Since we have a pretty stable spec (https://w3c.github.io/paint-timing/),
> lots of passing web platform tests, other browser vendor support and a
> working implementation of first contentful paint, I am planning to submit a
> patch to enable paint timing by default.
>
> https://bugs.webkit.org/show_bug.cgi?id=211736
>
> Any objections? Other thoughts?
> ___
> 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] Suggesting to enable paint timing by default

2020-05-11 Thread Maciej Stachowiak

I noticed from comments in one of the Radars that the patch may result in an 
additional “fake paint”, so it should probably be performance tested. Have you 
done any testing? We’ll likely want to A/B some of Apple’s page load speed 
benchmarks.

I’d like to hear from others on maturity of the spec and readiness of the code.

 - Maciej

> On May 11, 2020, at 11:44 AM, Noam Rosenthal  wrote:
> 
> Following the discussion with Simon in 
> https://bugs.webkit.org/show_bug.cgi?id=78011 
> 
> 
> Since we have a pretty stable spec (https://w3c.github.io/paint-timing/ 
> ), lots of passing web platform tests, 
> other browser vendor support and a working implementation of first contentful 
> paint, I am planning to submit a patch to enable paint timing by default. 
> 
> https://bugs.webkit.org/show_bug.cgi?id=211736 
> 
> 
> Any objections? Other thoughts?
> ___
> 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] Platform.h vs. makefiles

2020-05-11 Thread Maciej Stachowiak

I guess it depends on value of this (and feasibility of IDE highlighting based 
on a generated source file) vs value of having a common approach for 
compile-time and runtime flags. Runtime flags and their default values likely 
can’t be effectively expressed in headers.

Separate file also lets us do things like make build systems exclude files 
based on feature flag values, though of course, an alternative is to surround 
whole files with #include guards and always build everything.

> On May 11, 2020, at 9:34 AM, Alexey Proskuryakov  wrote:
> 
> 
> I see substantial appeal in having a separate data file, however I'm not sure 
> if it can inform IDE parsing and syntax highlighting for code 
> enabled/disabled at compile time. Header files seem like they would get that 
> right more often.
> 
> - Alexey
> 
> 
>> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak > > написал(а):
>> 
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
>> 
>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
>> 
>> -  Maciej
>> 
>>> On May 10, 2020, at 5:13 PM, Darin Adler >> > wrote:
>>> 
>>> Hi folks.
>>> 
>>> The Platform.h configuration file family has been useful for WebKit for a 
>>> long time. We created it to try to organize configuration options in WebKit 
>>> so the would not be spread out through the whole project.
>>> 
>>> One way to look at these, particularly the ENABLE options, is as a set of 
>>> configuration options that let each consumer of the WebKit source code 
>>> create a unique flavor of WebKit with the particular features they want 
>>> enabled turned on and others turned off. Another is to think of this as a 
>>> mechanism for keeping decisions made by the WebKit contributors organized 
>>> and easy to understand.
>>> 
>>> If these truly are WebKit consumer options, then it’s important they be set 
>>> as part of the build process. The macros can be defined with a build and 
>>> configuration system outside WebKit, and the Platform.h headers should 
>>> interpret those values correctly.
>>> 
>>> On the other hand, if we are just trying to keep our decisions straight, 
>>> then it would be best if the logic for what is on and what is off by in the 
>>> header files, written with preprocessor macro logic, and not spread across 
>>> multiple make files and scripts.
>>> 
>>> Thus I think the pattern on macOS, for example, of setting these in 
>>> .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files 
>>> should compute the things that need to be determined about the build 
>>> environment, but the configuration decisions should be in files like 
>>> PlatformHaveCocoa.h, for example.
>>> 
>>> I think the guideline should be like this:
>>> 
>>> All code to compute configuration should be in the Platform.h files, not in 
>>> makefiles, with only the following exceptions:
>>> 
>>> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
>>> people building WebKit can have overridden values in makefiles. But even 
>>> these options should have sensible defaults in the Platform.h headers that 
>>> express the current status of the port from the point of view of the port’s 
>>> maintainers. Ideally we’d find a way to not repeat these default settings 
>>> twice.
>>> 
>>> 2) In some cases, the build machinery needs to contribute to things like 
>>> feature detection. So on some platforms, things like HAVE(READLINE) would 
>>> be set correctly by the build system.
>>> 
>>> Options intended to be set by the environment would carefully be wrapped in 
>>> #ifndef.
>>> 
>>> But other options, which simply express relationships between configuration 
>>> elements, are designed to be set by Platform.h and not overridden by the 
>>> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
>>> and most USE options would fall into this category.
>>> 
>>> What do you all think?
>>> 
>>> — Darin
>>> ___
>>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Platform.h vs. makefiles

2020-05-11 Thread Maciej Stachowiak


> On May 10, 2020, at 11:11 PM, Darin Adler  wrote:
> 
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but 
> otherwise I do find this appealing. Perhaps some people would say that 
> FeatureDefines.props from cmake could be that file?
> 
> Not sure literally a single data file is the best way to do this across 
> multiple platforms/ports. I think PlatformEnableCocoa.h shows us that 
> breaking this down can be helpful.

> 
> One file that has the master list of all the settings, and all the default 
> values. Then other files that contain overlays for each port/configuration 
> where they are different from the default.


Yes, this is what I’d imagine. We could also add ability to inherit if we have 
configurations that want to share most but not all of their flag values. 
Additionally, we might need a way to express conditionals.

> My worry is that it could become complicated, like our TestExpectations 
> files, which were once simple.

It’s possible, but hopefully it could be limited to only necessary complexity.

>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
> 
> Yes, I’m not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h 
> header file instead. Unless the defines need to affect the build system and 
> not just the C++ code, I think the header file is superior.

That seems like a good direction.

 - Maciej

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


[webkit-dev] Suggesting to enable paint timing by default

2020-05-11 Thread Noam Rosenthal
Following the discussion with Simon in
https://bugs.webkit.org/show_bug.cgi?id=78011

Since we have a pretty stable spec (https://w3c.github.io/paint-timing/),
lots of passing web platform tests, other browser vendor support and a
working implementation of first contentful paint, I am planning to submit a
patch to enable paint timing by default.

https://bugs.webkit.org/show_bug.cgi?id=211736

Any objections? Other thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Platform.h vs. makefiles

2020-05-11 Thread Alexey Proskuryakov

I see substantial appeal in having a separate data file, however I'm not sure 
if it can inform IDE parsing and syntax highlighting for code enabled/disabled 
at compile time. Header files seem like they would get that right more often.

- Alexey


> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak  написал(а):
> 
> 
> I think the best way to configure WebKit is to use a separate data file, 
> neither a header nor a makefile or similar, that defines the options in a 
> single place with clear syntax. Then everything else is generated from that. 
> Such a system could cover runtime flags as well, which are even more 
> scattered around the project than compile-time flags.
> 
> Moving logic from build files to the header is probably a move in the right 
> direction, though of course it carries risk, particularly for less tested 
> configurations.
> 
> -  Maciej
> 
>> On May 10, 2020, at 5:13 PM, Darin Adler  wrote:
>> 
>> Hi folks.
>> 
>> The Platform.h configuration file family has been useful for WebKit for a 
>> long time. We created it to try to organize configuration options in WebKit 
>> so the would not be spread out through the whole project.
>> 
>> One way to look at these, particularly the ENABLE options, is as a set of 
>> configuration options that let each consumer of the WebKit source code 
>> create a unique flavor of WebKit with the particular features they want 
>> enabled turned on and others turned off. Another is to think of this as a 
>> mechanism for keeping decisions made by the WebKit contributors organized 
>> and easy to understand.
>> 
>> If these truly are WebKit consumer options, then it’s important they be set 
>> as part of the build process. The macros can be defined with a build and 
>> configuration system outside WebKit, and the Platform.h headers should 
>> interpret those values correctly.
>> 
>> On the other hand, if we are just trying to keep our decisions straight, 
>> then it would be best if the logic for what is on and what is off by in the 
>> header files, written with preprocessor macro logic, and not spread across 
>> multiple make files and scripts.
>> 
>> Thus I think the pattern on macOS, for example, of setting these in 
>> .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files 
>> should compute the things that need to be determined about the build 
>> environment, but the configuration decisions should be in files like 
>> PlatformHaveCocoa.h, for example.
>> 
>> I think the guideline should be like this:
>> 
>> All code to compute configuration should be in the Platform.h files, not in 
>> makefiles, with only the following exceptions:
>> 
>> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
>> people building WebKit can have overridden values in makefiles. But even 
>> these options should have sensible defaults in the Platform.h headers that 
>> express the current status of the port from the point of view of the port’s 
>> maintainers. Ideally we’d find a way to not repeat these default settings 
>> twice.
>> 
>> 2) In some cases, the build machinery needs to contribute to things like 
>> feature detection. So on some platforms, things like HAVE(READLINE) would be 
>> set correctly by the build system.
>> 
>> Options intended to be set by the environment would carefully be wrapped in 
>> #ifndef.
>> 
>> But other options, which simply express relationships between configuration 
>> elements, are designed to be set by Platform.h and not overridden by the 
>> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
>> and most USE options would fall into this category.
>> 
>> What do you all think?
>> 
>> — Darin
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Platform.h vs. makefiles

2020-05-11 Thread Michael Saboff
> On May 10, 2020, at 11:11 PM, Darin Adler  wrote:
> 
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but 
> otherwise I do find this appealing. Perhaps some people would say that 
> FeatureDefines.props from cmake could be that file?
> 
> Not sure literally a single data file is the best way to do this across 
> multiple platforms/ports. I think PlatformEnableCocoa.h shows us that 
> breaking this down can be helpful.
> 
> One file that has the master list of all the settings, and all the default 
> values. Then other files that contain overlays for each port/configuration 
> where they are different from the default.
> 
> My worry is that it could become complicated, like our TestExpectations 
> files, which were once simple.

One challenge with a data file approach is that all build systems need to be 
aware that it is the root dependency for most targets.  As such I don’t think 
it make sense to invent a new format, but to possibly refine the 
PlatformEnable*.h hierarchy.  Perhaps a new PlatformOverrides.h file that would 
only contain the overrides while the current PlatformEnable*.h contain the 
defaults.

>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
> 
> Yes, I’m not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h 
> header file instead. Unless the defines need to affect the build system and 
> not just the C++ code, I think the header file is superior.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] PSA: EWS bots aperez-{gtk, wpe}-ews offline for some days

2020-05-11 Thread Adrian Perez de Castro
Hi again,

On Sat, 2 May 2020 00:04:37 +0300, Adrian Perez de Castro  
wrote:
 
> Unfortunately, builders “aperez-gtk-ews” and “aperez-wpe-ews” will be offline
> for a few days: it is sitting at the office, where nobody is going these days,
> and I cannot get hold of it remotely. Next time I venture out I plan to stop
> by and bring it back online—but that may take until May 11th.

These two EWS builders are back online, and also they have been migrated away
from JHBuild and are now using Flatpak-based builds.

Regards,
—Adrián


signature.asc
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Platform.h vs. makefiles

2020-05-11 Thread Darin Adler
> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
> 
> I think the best way to configure WebKit is to use a separate data file, 
> neither a header nor a makefile or similar, that defines the options in a 
> single place with clear syntax. Then everything else is generated from that. 
> Such a system could cover runtime flags as well, which are even more 
> scattered around the project than compile-time flags.

Sounds OK. I worry a little about defining yet another language, but otherwise 
I do find this appealing. Perhaps some people would say that 
FeatureDefines.props from cmake could be that file?

Not sure literally a single data file is the best way to do this across 
multiple platforms/ports. I think PlatformEnableCocoa.h shows us that breaking 
this down can be helpful.

One file that has the master list of all the settings, and all the default 
values. Then other files that contain overlays for each port/configuration 
where they are different from the default.

My worry is that it could become complicated, like our TestExpectations files, 
which were once simple.

> Moving logic from build files to the header is probably a move in the right 
> direction, though of course it carries risk, particularly for less tested 
> configurations.

Yes, I’m not suggesting rushing to do it all at once in a mass change.

But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h header 
file instead. Unless the defines need to affect the build system and not just 
the C++ code, I think the header file is superior.

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