Hello,

On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak <m...@apple.com> wrote:

> > On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> >
> > 02.08.2017, 00:49, "Sam Weinig" <wei...@apple.com>:
> >>>  On Aug 1, 2017, at 6:57 AM, Dean Jackson <d...@apple.com> wrote:
> >>> 
> >>>>  On 24 Jul 2017, at 22:44, Brian Burg <bb...@apple.com> 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


Attachment: pgpLrd2mi2v3F.pgp
Description: PGP signature

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

Reply via email to