> On Aug 1, 2017, at 6:55 PM, Adrian Perez de Castro <[email protected]> wrote: > > Hello, > > On Tue, 01 Aug 2017 18:11:53 -0400, Maciej Stachowiak <[email protected] > <mailto:[email protected]>> wrote: > >>> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <[email protected]> wrote: >>> >>> 02.08.2017, 00:49, "Sam Weinig" <[email protected]>: >>>>> On Aug 1, 2017, at 6:57 AM, Dean Jackson <[email protected]> wrote: >>>>> >>>>>> On 24 Jul 2017, at 22:44, Brian Burg <[email protected]> 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 [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
