WEB_TIMING enabled on all ports - let's remove the flag?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WEB_TIMING enabled on all ports - let's remove the flag?

Brian Burg
Hi WebKittens,

In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.

It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?

If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.

Happy hacking,
        -Brian
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Dean Jackson-7


> On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>
> Hi WebKittens,
>
> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>
> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>
> If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.

In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.

Some others I see:

ENABLE_CANVAS_PATH
ENABLE_CSS_COMPOSITING
ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_FETCH_API
ENABLE_GEOLOCATION
ENABLE_INDEXED_DATABASE
ENABLE_STREAMS_API
ENABLE_CSS_SCROLL_SNAP
ENABLE_WEBGL
ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS

Dean

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Michael Catanzaro
We might want to keep ENABLE_GEOLOCATION since on our platform it pulls in a dependency that's not needed on embedded systems. I don't really care since I suspect it is small, but I bet somebody else will.

And I'm not sure about ENABLE_WEBGL. We have it forced on always, but we do allow disabling ENABLE_OPENGL and there is no dependency between those options. This looks like a bug in our feature defines.

The rest looks fine to me.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Sam Weinig-2
In reply to this post by Dean Jackson-7


> On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:
>
>
>
>> On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>>
>> Hi WebKittens,
>>
>> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>>
>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>>
>> If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>
> In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
>
> Some others I see:
>
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS


I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.

I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.

- Sam

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Michael Catanzaro
In reply to this post by Michael Catanzaro
On Tue, Aug 1, 2017 at 10:39 PM, Michael Catanzaro <[hidden email]> wrote:
We might want to keep ENABLE_GEOLOCATION since on our platform it pulls in a dependency that's not needed on embedded systems. I don't really care since I suspect it is small, but I bet somebody else will.

I think this applies to ENABLE_VIDEO as well. Of course that doesn't mean we should not consider removing these flags. Perhaps if any developers are working on projects that disable these flags, those developers should comment with statistics that measure the size impact of these features and their dependencies.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Konstantin Tokarev
In reply to this post by Sam Weinig-2


02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:

>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:
>>
>>>  On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>>>
>>>  Hi WebKittens,
>>>
>>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>>>
>>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>>>
>>>  If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>
>>  In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
>>
>>  Some others I see:
>>
>>  ENABLE_CANVAS_PATH
>>  ENABLE_CSS_COMPOSITING
>>  ENABLE_CSS_SELECTORS_LEVEL4
>>  ENABLE_FETCH_API
>>  ENABLE_GEOLOCATION
>>  ENABLE_INDEXED_DATABASE
>>  ENABLE_STREAMS_API
>>  ENABLE_CSS_SCROLL_SNAP
>>  ENABLE_WEBGL
>>  ENABLE_WEB_AUDIO
>>  ENABLE_WEB_SOCKETS
>
> I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.
>
> I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.

I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)

>
> - Sam
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

--
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Maciej Stachowiak
In reply to this post by Dean Jackson-7


On Aug 1, 2017, at 9:57 AM, Dean Jackson <[hidden email]> wrote:



On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:

Hi WebKittens,

In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.

It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?

If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.

In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.

I agree with this sentiment. I think a lot of these should never have been compile time flags. They should have been runtime (or at this point not flags at all).

Our Feature Policy addresses this: https://webkit.org/feature-policy/

"In some cases, compile time flags should be used in addition to or instead of runtime flags:
• When merely compiling a feature in significantly impacts the hackability or livability of trunk.
• When a feature requires a platform-specific back end that is not available on all platforms.
• When some ports or platforms have resource constraints which require the ability to remove the feature completely from builds.
• When a feature is otherwise only relevant to some ports or platforms.

That said, runtime flags are preferred whenever feasible."

Most of the flags listed below don't meet any of these conditions, and never did. It sounds like a few, like WebGL, might satisfy "When a feature requires a platform-specific backend that is not available on all platforms".

For any new features, we should strongly consider using runtime flags whenever possible. For many older features, it would be great to convert them to runtime flags even if they aren't ready to be enabled everywhere yet. Death to compile-time feature flags!

Some others I see:

ENABLE_CANVAS_PATH
ENABLE_CSS_COMPOSITING
ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_FETCH_API
ENABLE_GEOLOCATION
ENABLE_INDEXED_DATABASE
ENABLE_STREAMS_API

For Streams API, I think we're ready for Read Streams to be default on everywhere, but not yet Write Streams. I think Write Streams should be compiled in but runtime switched off by default until it's up to spec and fully qualified. (I don't remember how this maps to the flags exactly).

ENABLE_CSS_SCROLL_SNAP
ENABLE_WEBGL
ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS

Regards,
Maciej





_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Konstantin Tokarev
In reply to this post by Dean Jackson-7


01.08.2017, 16:58, "Dean Jackson" <[hidden email]>:

>>  On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>>
>>  Hi WebKittens,
>>
>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>>
>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>>
>>  If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>
> In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
>
> Some others I see:
>
> ENABLE_CANVAS_PATH
> ENABLE_CSS_COMPOSITING
> ENABLE_CSS_SELECTORS_LEVEL4
> ENABLE_FETCH_API
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE

IndexedDB makes no sense on devices without writable storage, so I think it would be better to keep this flag.

> ENABLE_STREAMS_API
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO
> ENABLE_WEB_SOCKETS
>
> Dean
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

--
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Maciej Stachowiak
In reply to this post by Konstantin Tokarev


> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[hidden email]> wrote:
>
>
>
> 02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:
>>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:
>>>
>>>>  On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>>>>
>>>>  Hi WebKittens,
>>>>
>>>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>>>>
>>>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>>>>
>>>>  If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>
>>>  In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
>>>
>>>  Some others I see:
>>>
>>>  ENABLE_CANVAS_PATH
>>>  ENABLE_CSS_COMPOSITING
>>>  ENABLE_CSS_SELECTORS_LEVEL4
>>>  ENABLE_FETCH_API
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_STREAMS_API
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>>  ENABLE_WEB_SOCKETS
>>
>> I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.
>>
>> I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.
>
> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)

I think all of the clients you mentioned actually do need video (or at least benefit from it). In any case, most clients like that don't usually bundle their own WebKit. They use a shared copy. Usually a copy that is also used by a web browser. So if they really want to disable video, they need a runtime flag, not a compile-time flag.

The port argument is potentially more compelling. It would carry more weight if there are platforms that can't supply the required back end at all, or where support is not expected any time soon. It's ok for new ports to be initially incomplete, using stubs or extra ifdefs that we wouldn't want upstream.

Regards,
Maciej



>
>>
>> - Sam
>>
>> _______________________________________________
>> webkit-dev mailing list
>> [hidden email]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> --
> Regards,
> Konstantin
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Konstantin Tokarev


02.08.2017, 01:12, "Maciej Stachowiak" <[hidden email]>:

>>  On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[hidden email]> wrote:
>>
>>  02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:
>>>>   On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:
>>>>
>>>>>   On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
>>>>>
>>>>>   Hi WebKittens,
>>>>>
>>>>>   In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
>>>>>
>>>>>   It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
>>>>>
>>>>>   If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
>>>>
>>>>   In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
>>>>
>>>>   Some others I see:
>>>>
>>>>   ENABLE_CANVAS_PATH
>>>>   ENABLE_CSS_COMPOSITING
>>>>   ENABLE_CSS_SELECTORS_LEVEL4
>>>>   ENABLE_FETCH_API
>>>>   ENABLE_GEOLOCATION
>>>>   ENABLE_INDEXED_DATABASE
>>>>   ENABLE_STREAMS_API
>>>>   ENABLE_CSS_SCROLL_SNAP
>>>>   ENABLE_WEBGL
>>>>   ENABLE_WEB_AUDIO
>>>>   ENABLE_WEB_SOCKETS
>>>
>>>  I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.
>>>
>>>  I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.
>>
>>  I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)
>
> I think all of the clients you mentioned actually do need video (or at least benefit from it). In any case, most clients like that don't usually bundle their own WebKit. They use a shared copy.

That's not true for Windows, where each application is shipping its own libraries, and is also not true for macOS in case port other than Mac is used. And such "small" applications surely benefit from reduced size and reduced dependencies.

>Usually a copy that is also used by a web browser. So if they really want to disable video, they need a runtime flag, not a compile-time flag.
>
> The port argument is potentially more compelling. It would carry more weight if there are platforms that can't supply the required back end at all, or where support is not expected any time soon. It's ok for new ports to be initially incomplete, using stubs or extra ifdefs that we wouldn't want upstream.
>
> Regards,
> Maciej
>
>>>  - Sam
>>>
>>>  _______________________________________________
>>>  webkit-dev mailing list
>>>  [hidden email]
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>  --
>>  Regards,
>>  Konstantin
>>  _______________________________________________
>>  webkit-dev mailing list
>>  [hidden email]
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev

--
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Michael Catanzaro
On Tue, Aug 1, 2017 at 11:32 PM, Konstantin Tokarev <[hidden email]> wrote:
That's not true for Windows, where each application is shipping its own libraries, and is also not true for macOS in case port other than Mac is used. And such "small" applications surely benefit from reduced size and reduced dependencies.

Of course it's also not true for embedded devices.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Maciej Stachowiak
In reply to this post by Konstantin Tokarev


On Aug 1, 2017, at 6:32 PM, Konstantin Tokarev <[hidden email]> wrote:



02.08.2017, 01:12, "Maciej Stachowiak" <[hidden email]>:
 On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[hidden email]> wrote:

 02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:
  On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:

  On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:

  Hi WebKittens,

  In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.

  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?

  If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.

  In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.

  Some others I see:

  ENABLE_CANVAS_PATH
  ENABLE_CSS_COMPOSITING
  ENABLE_CSS_SELECTORS_LEVEL4
  ENABLE_FETCH_API
  ENABLE_GEOLOCATION
  ENABLE_INDEXED_DATABASE
  ENABLE_STREAMS_API
  ENABLE_CSS_SCROLL_SNAP
  ENABLE_WEBGL
  ENABLE_WEB_AUDIO
  ENABLE_WEB_SOCKETS

 I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.

 I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.

 I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)

I think all of the clients you mentioned actually do need video (or at least benefit from it). In any case, most clients like that don't usually bundle their own WebKit. They use a shared copy. 

That's not true for Windows, where each application is shipping its own libraries, and is also not true for macOS in case port other than Mac is used. And such "small" applications surely benefit from reduced size and reduced dependencies. 

Chromium Embedded Framework is an obvious comparison project for use cases like that. CEF is arguably more popular as a bundled engine than WebKit, so we probably don't need more flexibility than they provide. Does CEF let you compile out video support?

Regards,
Maciej


Usually a copy that is also used by a web browser. So if they really want to disable video, they need a runtime flag, not a compile-time flag.

The port argument is potentially more compelling. It would carry more weight if there are platforms that can't supply the required back end at all, or where support is not expected any time soon. It's ok for new ports to be initially incomplete, using stubs or extra ifdefs that we wouldn't want upstream.

Regards,
Maciej

 - Sam

 _______________________________________________
 webkit-dev mailing list
 [hidden email]
 https://lists.webkit.org/mailman/listinfo/webkit-dev

 --
 Regards,
 Konstantin
 _______________________________________________
 webkit-dev mailing list
 [hidden email]
 https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Adrian Perez-10
In reply to this post by Maciej Stachowiak
Hello,

On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak <[hidden email]> wrote:

> > On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[hidden email]> wrote:
> >
> > 02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:
> >>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:
> >>>
> >>>>  On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:
> >>>>
> >>>>  Hi WebKittens,
> >>>>
> >>>>  In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.
> >>>>
> >>>>  It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?
> >>>>
> >>>>  If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.
> >>>
> >>>  In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.
In general I agree that build-time feature flags should go away once all ports
can have the feature enabled by default.

> >>>  Some others I see:
> >>>
> >>>  ENABLE_CANVAS_PATH
> >>>  ENABLE_CSS_COMPOSITING
> >>>  ENABLE_CSS_SELECTORS_LEVEL4
> >>>  ENABLE_FETCH_API
> >>>  ENABLE_GEOLOCATION
> >>>  ENABLE_INDEXED_DATABASE
> >>>  ENABLE_STREAMS_API
> >>>  ENABLE_CSS_SCROLL_SNAP
> >>>  ENABLE_WEBGL
> >>>  ENABLE_WEB_AUDIO
> >>>  ENABLE_WEB_SOCKETS
> >>
> >> I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.
> >>
> >> I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.
> >
> > I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)
>
> I think all of the clients you mentioned actually do need video (or at least benefit from it). In any case, most clients like that don't usually bundle their own WebKit. They use a shared copy. Usually a copy that is also used by a web browser. So if they really want to disable video, they need a runtime flag, not a compile-time flag.
Many embedded applications (embedded == not a browser, and the device does
not have a general-purpose one) ship their own build of WebKit, almost always
tailored to fit.

A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
are signage panels (typically some kind of info screens in a public space),
which most of the time show imagery and textual content, but no video or audio
at all, running on small embedded computers where on-disk size and memory
usage matter. For this kind of application it also makes sense to support
ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
nor any other kind of sound output.

Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
does not need GStreamer at all, which further reduces disk and memory usage.
For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

Cheers,

--
 Adrián 🎩

---
[1] https://git.busybox.net/buildroot/tree/package/webkitgtk/webkitgtk.mk#n37



_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Maciej Stachowiak


On Aug 1, 2017, at 6:55 PM, Adrian Perez de Castro <[hidden email]> wrote:

Hello,

On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak <[hidden email]> wrote:

On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[hidden email]> wrote:

02.08.2017, 00:49, "Sam Weinig" <[hidden email]>:
On Aug 1, 2017, at 6:57 AM, Dean Jackson <[hidden email]> wrote:

On 24 Jul 2017, at 22:44, Brian Burg <[hidden email]> wrote:

Hi WebKittens,

In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.

It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems by default, and we have not experienced any fallout from shipping these features in Safari Technology Preview. I think it’s time to remove the feature flag. Are there any objections? Is there a port in-tree that’s compiling without this feature?

If I don’t hear anything, the flag’s removal will be tracked in <https://bugs.webkit.org/show_bug.cgi?id=174795>.

In general I think we should be more enthusiastic about removing feature flags that are guarding core parts of the Web platform. Web Timing is a great example.

In general I agree that build-time feature flags should go away once all ports
can have the feature enabled by default.

Some others I see:

ENABLE_CANVAS_PATH
ENABLE_CSS_COMPOSITING
ENABLE_CSS_SELECTORS_LEVEL4
ENABLE_FETCH_API
ENABLE_GEOLOCATION
ENABLE_INDEXED_DATABASE
ENABLE_STREAMS_API
ENABLE_CSS_SCROLL_SNAP
ENABLE_WEBGL
ENABLE_WEB_AUDIO
ENABLE_WEB_SOCKETS

I think WebGL is still not supported on Windows in WebKitLegacy, so we may need to keep that one.

I’d like to add ENABLE_VIDEO to that list, given how core it is to the platform, and how many other features depend on it.

I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are lots of non-browser applications that need HTML renderer (document viewers, mail clients, instant messengers, RSS readers, etc.) which don't need video, but also because it greatly raises the bar for implementing new ports (e.g. recently announced Android port didn't implement video at that time)

I think all of the clients you mentioned actually do need video (or at least benefit from it). In any case, most clients like that don't usually bundle their own WebKit. They use a shared copy. Usually a copy that is also used by a web browser. So if they really want to disable video, they need a runtime flag, not a compile-time flag.

Many embedded applications (embedded == not a browser, and the device does
not have a general-purpose one) ship their own build of WebKit, almost always
tailored to fit.

A good example of an use-case that benefits from supporting ENABLE_VIDEO=OFF
are signage panels (typically some kind of info screens in a public space),
which most of the time show imagery and textual content, but no video or audio
at all, running on small embedded computers where on-disk size and memory
usage matter. For this kind of application it also makes sense to support
ENABLE_WEB_AUDIO=OFF, as the hardware usually does not even have speakers
nor any other kind of sound output.

Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO
does not need GStreamer at all, which further reduces disk and memory usage.
For example Buildroot includes a WebKitGTK+ recipe which can disable both [1]
precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

That sound somewhat more compelling to me than apps for desktop platforms that bundle their own WebKit.

Regards,
Maciej


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Michael Catanzaro
In reply to this post by Adrian Perez-10
On Tue, Aug 1, 2017 at 11:55 PM, Adrian Perez de Castro <[hidden email]> wrote:
Moreover, for the WebKitGTK+ disabling both ENABLE_VIDEO and ENABLE_WEB_AUDIO does not need GStreamer at all, which further reduces disk and memory usage. For example Buildroot includes a WebKitGTK+ recipe which can disable both [1] precisely for this reason. So I would also keep ENABLE_WEB_AUDIO.

Good point. Avoiding the GStreamer dependency is significant. I suspect we have more projects besides digital signage that disable both of these build flags, so it would probably be convenient for Igalia if these flags were retained. Although it is annoying to see how often we get bug reports about the ENABLE_VIDEO=OFF build being broken, I suppose that in itself is evidence that the flag is in regular use.

I'm sure we can still identify a large number of other build flags to be removed. There is a lot of low-hanging fruit here!

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

pulkomandy
> Some others I see:
>
> ENABLE_GEOLOCATION
> ENABLE_INDEXED_DATABASE
> ENABLE_CSS_SCROLL_SNAP
> ENABLE_WEBGL
> ENABLE_WEB_AUDIO

At least these are still not implemented in the Haiku port. I know we
are not an upstream port anymore and have little chance of being again
as I'm slowly trying to catch up with the lates 1.5 years of
development in WebKit. But having to implement all of these would
delay my work even more.

As usual, I don't want the Haiku port to pull WebKit backwards, and I
do plan to implement some of these at some point. However, being able
to disable them at least for some time lets me work on other, more
important aspects of the port first.

If the compile time flags are too annoying for that, maybe an
alternative would be to provide stub implementations, but then support
for these features should still not be advertised to webpages if the
port really doesn't support them.

--
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Ryosuke Niwa-2
On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues <[hidden email]> wrote:

>> Some others I see:
>>
>> ENABLE_GEOLOCATION
>> ENABLE_INDEXED_DATABASE
>> ENABLE_CSS_SCROLL_SNAP
>> ENABLE_WEBGL
>> ENABLE_WEB_AUDIO
>
> At least these are still not implemented in the Haiku port. I know we
> are not an upstream port anymore and have little chance of being again
> as I'm slowly trying to catch up with the lates 1.5 years of
> development in WebKit. But having to implement all of these would
> delay my work even more.
>
> As usual, I don't want the Haiku port to pull WebKit backwards, and I
> do plan to implement some of these at some point. However, being able
> to disable them at least for some time lets me work on other, more
> important aspects of the port first.
>
> If the compile time flags are too annoying for that, maybe an
> alternative would be to provide stub implementations, but then support
> for these features should still not be advertised to webpages if the
> port really doesn't support them.

I can see an argument for having build flags for ENABLE_GEOLOCATION,
ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
all more or less require some external dependency (e.g. sqlite) and
platform features (e.g. audio).

Perhaps we could merge some build flags though. e.g. we could merge
ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
can only enable both or neither.

- R. Niwa
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Brady Eidson

> On Aug 1, 2017, at 11:18 PM, Ryosuke Niwa <[hidden email]> wrote:
>
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues <[hidden email]> wrote:
>>> Some others I see:
>>>
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>>
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>>
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>>
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

INDEXED_DATABASE can be built and used without the SQLite dependency; We have our own fully supported in-memory backing store for private browsing that could be used by any port for mainline browsing as well.
In fact, the in-memory store would be a fine default store for a port that doesn't even specify an IDB database directly.

At this point in the web platform and the lifecycle of IndexedDB I think it's problematic for any port to pretend it doesn't exist.

I support removing this one, as well.

Thanks,
 Brady

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Konstantin Tokarev
In reply to this post by Ryosuke Niwa-2


02.08.2017, 09:19, "Ryosuke Niwa" <[hidden email]>:

> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues <[hidden email]> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know we
>>  are not an upstream port anymore and have little chance of being again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and I
>>  do plan to implement some of these at some point. However, being able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia player" library,
while ENABLE_WEB_AUDIO requires more advanced audio processing features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to real
website which is not WebAudio demo but makes use of this API somehow?

>
> - R. Niwa
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

--
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WEB_TIMING enabled on all ports - let's remove the flag?

Gustavo Sverzut Barbieri-4
In reply to this post by Maciej Stachowiak
On Tue, Aug 1, 2017 at 7:54 PM, Maciej Stachowiak <[hidden email]> wrote:
> Chromium Embedded Framework is an obvious comparison project for use cases
> like that. CEF is arguably more popular as a bundled engine than WebKit, so
> we probably don't need more flexibility than they provide. Does CEF let you
> compile out video support?

not sure, but they do offer the video pipeline internally via
ffmpeg... thus it's not spread across ports as we do. Similar cases
come from rendering system, they force one and thus remove some
options because all ports will implement a feature, unlike here where
most features are port-dependent.

--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN, GTalk, FaceTime: [hidden email]
Skype: gsbarbieri
Mobile: +55 (16) 99354-9890
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
12
Loading...