Re: [webkit-dev] On web-exposing features disabled at runtime
En 10/02/14 22:38, Benjamin Poulain escribiu: > On 2/10/14, 10:40 AM, Sergio Villar Senin wrote: >> The question is whether this is an acceptable behavior or not, and how >> to fix it in case we don't like it. I guess it's safe to conclude that >> it isn't something that we want in general, as it might confuse web >> authors (they see the how properties are available but do nothing). >> Regarding how to fix it, I guess the idea is to do something similar to >> what Eric did in Blink last year[2], i.e., filtering out the list of >> properties that are runtime disabled. >> >> Opinions? > > Can't we add a compile time flag instead? > The chromium patch you linked is inelegant and it touches some hot paths. > > Another advantage of compile time flag is Andreas eventually notice when > they become useless and remove all the unnecessary cruft ;) Heh, then I won't make his life easier ;) Seriously speaking, there was a feature flag that was removed in https://bugs.webkit.org/show_bug.cgi?id=86767. Let's bring it to life. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL and GTK on Darwin
Hello Dan, >> 1. Is there a configuration of the EFL port that actually builds for Darwin? Unfortunately(?), AFAIK, WebKit EFL port doesn't support Darwin OS yet. Gyuyoung. On Tue, Feb 11, 2014 at 11:30 AM, Dan Bernstein wrote: > Hi everyone, and especially EFL and GTK contributors! > > In preparation for changing PLATFORM(MAC) to be false when building for > iOS, I have been reviewing usage of PLATFORM(MAC) throughout our > codebase. Some of these uses are really about targeting the Darwin OS. > However, I could not simply replace PLATFORM(MAC) with OS(DARWIN), > because the latter also encompasses the EFL and GTK platforms when building > for Darwin (which the former does not). Therefore, thus far I have replaced > relevant instances of PLATFORM(MAC) with (OS(DARWIN) && !PLATFORM(EFL) && > !PLATFORM(GTK)). > > This is ugly and seems like a waste of time, so I was wondering: > > 1. Is there a configuration of the EFL port that actually builds for > Darwin? > > 2. Is there a configuration of the GTK port that actually builds for > Darwin? > > 3. If such configuration(s) exist, would it be OK for them to use Darwin > when building for Darwin? > > If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will > simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent, > and, depending on the answers to 1 and 2, update the EFL and GTK build > systems to include the Darwin-based implementations where needed. > > Thanks! > > ___ > 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] EFL and GTK on Darwin
Hi everyone, and especially EFL and GTK contributors! In preparation for changing PLATFORM(MAC) to be false when building for iOS, I have been reviewing usage of PLATFORM(MAC) throughout our codebase. Some of these uses are really about targeting the Darwin OS. However, I could not simply replace PLATFORM(MAC) with OS(DARWIN), because the latter also encompasses the EFL and GTK platforms when building for Darwin (which the former does not). Therefore, thus far I have replaced relevant instances of PLATFORM(MAC) with (OS(DARWIN) && !PLATFORM(EFL) && !PLATFORM(GTK)). This is ugly and seems like a waste of time, so I was wondering: 1. Is there a configuration of the EFL port that actually builds for Darwin? 2. Is there a configuration of the GTK port that actually builds for Darwin? 3. If such configuration(s) exist, would it be OK for them to use Darwin when building for Darwin? If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent, and, depending on the answers to 1 and 2, update the EFL and GTK build systems to include the Darwin-based implementations where needed. Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL backends
Hi, EFL port is using GraphicsContext3D and configurable for OpenGLES or OpenGL. On Feb 9, 2014, at 2:59 PM, Dean Jackson wrote: > Hi floks. > > I’m looking into simplifying our WebGL code, particularly our > GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL > backend for its ports, but it isn’t clear to me what backend the other ports > are using. > > Could the other port developers please reply to let me know how you’re > accessing OpenGL? > > Thanks, > > Dean > > ___ > webkit-dev mailing list > webkit-dev at 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] EWS doesn't lie!
All of this makes sense, but the downsides is that it does not ensure convergence between the ports. If this situation is expected to stay for some time, I wonder whether some middle ground may be found for ports that are build-stable. For instance, having status information on new/modified tests for all ports would be useful and not that expensive. When tests do not pass on some ports, updating the test expectations (and creating bug entries) would be an improvement over the current situation. 2014-02-10 10:25 GMT+01:00 Osztrogonác Csaba : > On 02/10/2014 09:51 AM, youenn fablet wrote: > >> Is it by design that only mac bots run regression tests? Technical >> issue? Lack of resources? >> > > Technically, it's so easy to make an EWS to run layout tests > too with adding a "runTests": true" to the ews.json file: > https://trac.webkit.org/browser/trunk/Tools/Scripts/ > webkitpy/common/config/ews.json > > But in my opinion it wouldn't be a good idea to enable layout tests > on Windows, GTK, EFL EWS bots, because it would make them absolutely > useless and we would lost the information if a patch builds or not. > > To have a quite stable and working tester EWS, the buildbot for the > given platform must be green _almost all the time_. If there is at > least one failing test, the testing is at least twice slower, because > the EWS runs the test with the patch and then without the patch to > check if the list of the failing tests are same. Additionally the > given port must be very stable. If there are any small flakiness, > the EWS wouldn't pass ever and would stuck in an infinite loop. > > The rough true is that now only the Mac platform is stable and green > enough to have tester EWS bots. (There are ~210 +/-5 failures on the > Windows bots from the cstack merge, ~205 +/-10 failures on EFL-WK1 long > time ago, ~80 +/- 2 failures on GTK-WK1 lone time ago, ~ 60 +/- 5 > failures on GTK-WK2, ...) > > Additionally to have tester EWS, port maintainers should have to setup > many new hardware (min. 4-8 machines with 4/8 cores per port to have > acceptable runtime) and EWS runtime would be much more slower than > the runtime of build only EWS bots, because bulding + running tests > take ~ an hour everywhere. > > Ossy > > > ___ > 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] On web-exposing features disabled at runtime
On 2/10/14, 10:40 AM, Sergio Villar Senin wrote: I'm sending this to the list because it might affect different components inside the project. So as smfr correctly reported here[1] for all those features that don't have a feature flag (like grid layout) we're web-exposing the CSS properties of the feature even if it's disabled at runtime (we're exposing them as well for features enabled at build time but disabled at runtime). If I am not wrong, we just disable the parsing of those properties that are not runtime enabled, but the properties are exposed anyway, something easy to check doing for example: Object.getOwnPropertyDescriptor(document.body.style, property-name). Yep that is bad. The question is whether this is an acceptable behavior or not, and how to fix it in case we don't like it. I guess it's safe to conclude that it isn't something that we want in general, as it might confuse web authors (they see the how properties are available but do nothing). Regarding how to fix it, I guess the idea is to do something similar to what Eric did in Blink last year[2], i.e., filtering out the list of properties that are runtime disabled. Opinions? Can't we add a compile time flag instead? The chromium patch you linked is inelegant and it touches some hot paths. Another advantage of compile time flag is Andreas eventually notice when they become useless and remove all the unnecessary cruft ;) Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On web-exposing features disabled at runtime
On Feb 10, 2014, at 10:40 AM, Sergio Villar Senin wrote: > Hi folks, > > I'm sending this to the list because it might affect different > components inside the project. > > So as smfr correctly reported here[1] for all those features that don't > have a feature flag (like grid layout) we're web-exposing the CSS > properties of the feature even if it's disabled at runtime (we're > exposing them as well for features enabled at build time but disabled at > runtime). > > If I am not wrong, we just disable the parsing of those properties that > are not runtime enabled, but the properties are exposed anyway, > something easy to check doing for example: > Object.getOwnPropertyDescriptor(document.body.style, property-name). > > The question is whether this is an acceptable behavior or not, and how > to fix it in case we don't like it. I guess it's safe to conclude that > it isn't something that we want in general, as it might confuse web > authors (they see the how properties are available but do nothing). > Regarding how to fix it, I guess the idea is to do something similar to > what Eric did in Blink last year[2], i.e., filtering out the list of > properties that are runtime disabled. It's not a good behavior, in my opinion. I am not an expert on the CSS parser, but I think we should hide the CSS interface for runtime-disabled features. That would allow us to consider runtime disabling instead of prefixing as a tool for early testing in more cases. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] On web-exposing features disabled at runtime
Hi folks, I'm sending this to the list because it might affect different components inside the project. So as smfr correctly reported here[1] for all those features that don't have a feature flag (like grid layout) we're web-exposing the CSS properties of the feature even if it's disabled at runtime (we're exposing them as well for features enabled at build time but disabled at runtime). If I am not wrong, we just disable the parsing of those properties that are not runtime enabled, but the properties are exposed anyway, something easy to check doing for example: Object.getOwnPropertyDescriptor(document.body.style, property-name). The question is whether this is an acceptable behavior or not, and how to fix it in case we don't like it. I guess it's safe to conclude that it isn't something that we want in general, as it might confuse web authors (they see the how properties are available but do nothing). Regarding how to fix it, I guess the idea is to do something similar to what Eric did in Blink last year[2], i.e., filtering out the list of properties that are runtime disabled. Opinions? BR [1] https://bugs.webkit.org/show_bug.cgi?id=128271 [2] https://codereview.chromium.org/14324009 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ports relying on ICU with features omitted?
On Feb 10, 2014, at 9:54 AM, Brent Fulgham wrote: > I believe that the dim3 game engine (http://www.klinksoftware.net) uses > JavaScriptCore with a custom ICU. I don’t remember what ICU features they > exclude, but they might be impacted by this change. Understood. But to be clear, I’m asking about active ports in the WebKit project, not those who use the software downstream without contributing directly. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ports relying on ICU with features omitted?
Hi Darin, On Feb 10, 2014, at 9:40 AM, Darin Adler wrote: > I’d like to find out which ports are relying on WebKit support for ICU > without certain key features. Maintaining these extra code paths creates some > difficulties, and it would be helpful to remove them once no one is relying > them. For example, we have support for: > > […] > I know this is not needed for PLATFORM(MAC), PLATFORM(IOS), and PLATFORM(WIN). > > So I guess I am looking for an answer for PLATFORM(GTK) and PLATFORM(EFL) and > any others I might have forgotten to ask about. I believe that the dim3 game engine (http://www.klinksoftware.net) uses JavaScriptCore with a custom ICU. I don’t remember what ICU features they exclude, but they might be impacted by this change. I suspect they could follow WinCE’s approach if this was a significant problem for them. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL backends
On 10 Feb 2014, at 9:27 am, Steven Coul (scoul) wrote: > > Would this be simplify as in tidy up existing code, get down to a simple > subset of required functionality, and maybe abstracting the (E)GL part? > > Or are you considering a simplification by just saying it will be EGL version > X, and OpenGL version Y from now on and nothing else? No, I was just hoping there was a chance to reduce the number of implementations, but it seems they are all actively used. There might still be an opportunity to collect shared functionality (Alex mentioned Windows) but that was the existing design goal anyway, so it would be minor changes if any. Thanks to everyone who responded. Dean > > > Steve "Harry" Coul > sc...@cisco.com > > > > On Feb 9, 2014, at 2:59 PM, Dean Jackson wrote: > >> Hi floks. >> >> I’m looking into simplifying our WebGL code, particularly our >> GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL >> backend for its ports, but it isn’t clear to me what backend the other ports >> are using. >> >> Could the other port developers please reply to let me know how you’re >> accessing OpenGL? >> >> Thanks, >> >> Dean >> >> ___ >> 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] Ports relying on ICU with features omitted?
Hi folks. I’d like to find out which ports are relying on WebKit support for ICU without certain key features. Maintaining these extra code paths creates some difficulties, and it would be helpful to remove them once no one is relying them. For example, we have support for: UCONFIG_NO_COLLATION: There is and absurdly simplistic, not-even-case-folding sorting code path in WTF::Collator and a dumbed down text searching code path in WebCore::SearchBuffer if a platform has ICU configured without collation features. UCONFIG_NO_FORMATTING: We have multiple code paths to format dates in JavaScriptCore::DatePrototype, skipping the ICU one if a platform has ICU configured without formatting features. Is anyone relying on these? If a platform lacks ICU entirely, such as WinCE, we have decided to use an approach where it supplies code that matches ICU’s interface. Such platforms should do that for the collation and formatting features. So I’m not interested in those. Rather, I’m interested in platforms where we are using ICU, but the copy of ICU is being built with features turned off. I know this is not needed for PLATFORM(MAC), PLATFORM(IOS), and PLATFORM(WIN). So I guess I am looking for an answer for PLATFORM(GTK) and PLATFORM(EFL) and any others I might have forgotten to ask about. Can you help? — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL backends
On Mon, Feb 10, 2014 at 9:16 AM, Brent Fulgham wrote: > I’m pretty sure the GTK+ port uses OpenGL directly, but Martin Robinson can > probably confirm that. The GTK+ port uses the OpenGL or OpenGLES GraphicsContext3D depending on the system it is compiled on and configuration options. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL backends
Would this be simplify as in tidy up existing code, get down to a simple subset of required functionality, and maybe abstracting the (E)GL part? Or are you considering a simplification by just saying it will be EGL version X, and OpenGL version Y from now on and nothing else? Steve "Harry" Coul sc...@cisco.com On Feb 9, 2014, at 2:59 PM, Dean Jackson wrote: > Hi floks. > > I’m looking into simplifying our WebGL code, particularly our > GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL > backend for its ports, but it isn’t clear to me what backend the other ports > are using. > > Could the other port developers please reply to let me know how you’re > accessing OpenGL? > > Thanks, > > Dean > > ___ > 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] WebGL backends
Hi Dean, The WinCairo port uses the ANGLE library (and therefore, the “OpenGL” machinery) to do WebGL. I’m pretty sure the GTK+ port uses OpenGL directly, but Martin Robinson can probably confirm that. I think that only really leaves EFL, which may be using OpenGLES? I’m not sure. -Brent On Feb 9, 2014, at 12:59 PM, Dean Jackson wrote: > Hi floks. > > I’m looking into simplifying our WebGL code, particularly our > GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL > backend for its ports, but it isn’t clear to me what backend the other ports > are using. > > Could the other port developers please reply to let me know how you’re > accessing OpenGL? > > Thanks, > > Dean > > ___ > 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] EWS doesn't lie!
On 02/10/2014 09:51 AM, youenn fablet wrote: Is it by design that only mac bots run regression tests? Technical issue? Lack of resources? Technically, it's so easy to make an EWS to run layout tests too with adding a "runTests": true" to the ews.json file: https://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/ews.json But in my opinion it wouldn't be a good idea to enable layout tests on Windows, GTK, EFL EWS bots, because it would make them absolutely useless and we would lost the information if a patch builds or not. To have a quite stable and working tester EWS, the buildbot for the given platform must be green _almost all the time_. If there is at least one failing test, the testing is at least twice slower, because the EWS runs the test with the patch and then without the patch to check if the list of the failing tests are same. Additionally the given port must be very stable. If there are any small flakiness, the EWS wouldn't pass ever and would stuck in an infinite loop. The rough true is that now only the Mac platform is stable and green enough to have tester EWS bots. (There are ~210 +/-5 failures on the Windows bots from the cstack merge, ~205 +/-10 failures on EFL-WK1 long time ago, ~80 +/- 2 failures on GTK-WK1 lone time ago, ~ 60 +/- 5 failures on GTK-WK2, ...) Additionally to have tester EWS, port maintainers should have to setup many new hardware (min. 4-8 machines with 4/8 cores per port to have acceptable runtime) and EWS runtime would be much more slower than the runtime of build only EWS bots, because bulding + running tests take ~ an hour everywhere. Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EWS doesn't lie!
On Feb 10, 2014, at 12:51 AM, youenn fablet wrote: > Is it by design that only mac bots run regression tests? Certainly not. > Technical issue? I think so; look at http://build.webkit.org/dashboard/; the Mac port is the only one that’s even close to green enough to make running the tests on EWS worthwhile (i.e. insufficiently noisy that new failures are possible to distinguish). > Lack of resources? Could be this too, but I can’t speak for the other ports. It takes a good number of machines to keep up (and Mac starts falling behind as soon as someone introduces a flaky test because of EWS’s slightly odd machinery). > > 2014-01-30 9:05 GMT+01:00 Alexey Proskuryakov : > Hi WebKit hackers, > > It sometimes happens that people land patches despite EWS detecting layout > test regressions, especially when these seem too unlikely to believe. > > In my experience, EWS has been very stable recently, and if tester bubbles > are red, it almost certainly means that the patch is faulty. Even if they > don't turn red, but remain yellow for a long time, there is a good chance > that the patch introduces flaky failures, so EWS can't make up its mind about > exactly which tests regressed. > > If you click on a yellow bubble, that takes you to a page with additional > details, where you can see which tests are failing. I'd like to look into > improving how this information is presented at some point in the future, yet > even now, it shouldn't be too time consuming to check what's going on. > > For reference, we currently have mac and mac-wk2 EWS bots running regression > tests in release mode. Other bots only verify that the patch builds, and > don't run tests. No bots use debug mode as far as I know, so debug-only build > failures and assertions will not be detected. Please run tests locally to > catch as many of those as possible. > > - WBR, Alexey Proskuryakov > > ___ > 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] EWS doesn't lie!
Is it by design that only mac bots run regression tests? Technical issue? Lack of resources? 2014-01-30 9:05 GMT+01:00 Alexey Proskuryakov : > Hi WebKit hackers, > > It sometimes happens that people land patches despite EWS detecting layout > test regressions, especially when these seem too unlikely to believe. > > In my experience, EWS has been very stable recently, and if tester bubbles > are red, it almost certainly means that the patch is faulty. Even if they > don't turn red, but remain yellow for a long time, there is a good chance > that the patch introduces flaky failures, so EWS can't make up its mind > about exactly which tests regressed. > > If you click on a yellow bubble, that takes you to a page with additional > details, where you can see which tests are failing. I'd like to look into > improving how this information is presented at some point in the future, > yet even now, it shouldn't be too time consuming to check what's going on. > > For reference, we currently have mac and mac-wk2 EWS bots running > regression tests in release mode. Other bots only verify that the patch > builds, and don't run tests. No bots use debug mode as far as I know, so > debug-only build failures and assertions will not be detected. Please run > tests locally to catch as many of those as possible. > > - WBR, Alexey Proskuryakov > > ___ > 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
