Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)
Le 24/10/2017 à 09:19, Frédéric WANG a écrit : On 23/10/2017 18:25, Adrian Perez de Castro wrote: > From your description it sounds that what takes more disk space in MathML are > the needed math fonts, and that the amount of code added to WebKit when built > is in the order of hundreds of kilobytes, at most (BTW, do you have figures of > MathML enabld vs. disabled to confirm?). That being the case, it seems fine to > me that MathML support is always enabled. > > Usually my main concern with removing compilation guards is forcing additional > usage of megabytes of disk and/or memory in embedded platforms (which is, for > example, the case for ENABLE_VIDEO: for the GTK+ and WPE ports it completely > avoids the GStreamer dependency, which saves tens of megabytes!). But keeping > the guards to save just a few hundreds of kilobytes is certainly not worth it, > and in this case embedders can choose to not ship the math fonts. > > TL;DR: Fine by me, as it seems the compile flag only saves a few kilobytes in > the built binaries, and the math fonts can't be skipped anyway by embedders. Thanks Adrián. No, I wanted to do it during the Web Engines Hackfest but did not have time to try. Also, Olivier mentioned he would check the difference and tell whether it is significant or not for his project, but I have not heard back from him yet. Hi, The difference is about 250 kB on libWPEWebKit.so.0 for a WPE build on my ARMv7 target: - without MathML : 37474160 - with MathML: 37726056 This can still be significant on low-end devices, with 128 MB of flash storage. -- Olivier Blin - SoftAtHome ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: upstream the WPE port
Le 24/04/2017 à 17:57, Brady Eidson a écrit : >> I do *not* support adding another client of the C API, even in the >> interim. > > It would be easier for us to move to the new API after the port is > upstream, since it will require refactorings in both ports GTK+ and WPE > . So, we can simply remove from the current patch anything added to the > C API (except the web view implementation or whatever is needed by WTR) > and then work on moving to the new API in follow up patches. > > Are you ok with that? In the coming weeks I am actually likely to be changing and/or removing at least a few functions from the C-API. As long as the WPE upstreaming effort is comfortable with the idea that I might be breaking them as they go… That’s fine. Hi, I can not speak for all WPE users, as we are far from being the biggest or most active user of WPE. But for reference, below is a list of the C APIs that we use, a few being specific to WPE. WKArrayCreateAdoptingValues WKArrayGetItemAtIndex WKArrayGetSize WKContextCreateWithInjectedBundlePath WKContextGetCookieManager WKContextSetClient WKCookieManagerSetCookiePersistentStorage WKErrorCopyDomain WKErrorCopyFailingURL WKErrorCopyLocalizedDescription WKErrorGetErrorCode WKPageClose WKPageConfigurationCreate WKPageConfigurationSetContext WKPageConfigurationSetPageGroup WKPageCopyActiveURL WKPageCopyUserAgent WKPageGroupAddUserScript WKPageGroupCreateWithIdentifier WKPageGroupSetPreferences WKPageLoadURL WKPageRunJavaScriptAlertResultListenerCall WKPageRunJavaScriptConfirmResultListenerCall WKPageRunJavaScriptPromptResultListenerCall WKPageSetCustomUserAgent WKPageSetPageInjectedBundleClient WKPageSetPageLoaderClient WKPageSetPageUIClient WKPageTryClose WKPreferencesCreate WKPreferencesSetAllowDisplayOfInsecureContent WKPreferencesSetLogsPageMessagesToSystemConsoleEnabled WKRelease WKSoupSessionSetIgnoreTLSErrors WKSoupSessionSetPreferredLanguages WKStringCreateWithUTF8CString WKStringGetMaximumUTF8CStringSize WKStringGetUTF8CString WKStringIsEqualToUTF8CString WKUInt64GetValue WKURLCopyString WKURLCreateWithBaseURL WKURLCreateWithUTF8CString WKUserMediaPermissionRequestAllow WKUserMediaPermissionRequestAudioDeviceUIDs WKUserMediaPermissionRequestVideoDeviceUIDs WKViewCreate WKViewGetPage Thanks -- Olivier Blin - SoftAtHome ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: upstream the WPE port
Hello, I am hopping in as a WPE user. The WPE port is gaining momentum in the set-top box world, and mainly within the RDK consortium, which gathers many cable/TV/network operators and software vendors. The company I work for plans to deploy WPE on hundreds of thousands set-top boxes soon, and we are just a small user in the RDK community. Our contributions are pretty modest for now, but relevant for some other ports, like the initial switch from GnuTLS to libgcrypt for crypto, or WebP animations support (in progress). We plan to contribute more in the coming weeks around MSE/EME for the GStreamer backend. Many set-top box vendors previously used QtWebKit, and WPE is now the obvious choice since it brings the quality and stability of the Gtk port with a lightweight approach. WPE is very actively maintained by Igalia, and this really encourages operators to keep in sync with upstream WebKit. There is also a RDK working group focused on the WPE browser, with regular meetings, where operators are committed to use and maintain WPE. Hope this helps, it would be great to have other operators chime in here. Thanks Zan! Le 21/04/2017 à 23:24, Alex Christensen a écrit : This is exciting news, Zan! I’m happy to see innovative new uses of WebKit. What kind of groups hope to use this new port? What kind of groups hope to maintain this new port? Will it be beneficial to the WebKit community to have their cooperative work? I see having more groups motivated to organize things in a supportable way as positive. -- Olivier Blin - SoftAtHome ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Thought about Nix JavaScriptCore port
Le 10/02/2016 17:28, Darin Adler a écrit : That’s going to change over time. We have frequently changed which functions and sections of ICU we use as we develop WebKit. That being said, there is no harm in someone carefully researching exactly what parts of ICU WebKit uses at a particular point in time. Maybe since the two of you both want it, one of you would like to volunteer to do that? I’m not sure there’s anyone else planning on it. (resending to ML) Hi, I have similar concerns for building on a set-top box environment, and have prepared a patch series to fix build with a light ICU. This has been initially done on WebKitForWayland, but it applies to any port. See the following bugs: https://bugs.webkit.org/show_bug.cgi?id=154479 https://bugs.webkit.org/show_bug.cgi?id=154482 https://bugs.webkit.org/show_bug.cgi?id=154483 https://bugs.webkit.org/show_bug.cgi?id=154484 With proper stripping, ICU lib/resources can be around 3.5 MB. Hope this helps -- Olivier Blin - SoftAtHome ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
