Re: [webkit-dev] webkit vs webkit 2 , svg functionality

[Dean Jackson]

Saba,

It seems no one answered your question so I'll take a stab.

On 24/04/2011, at 5:26 AM, Saba Taseer wrote:

> I am new to webkit and trying to understand its api and processes. I have 
> been experimenting with winlaumcher and mini browser projects on windows. I 
> tried to load an svg circle from winlauncher and I was able to trace a call 
> to svg circle element :: create function. Then I moved to mini browser. I 
> wrote the circle code in a file and wrote its url in the minibrowser window. 
> I couldnot trace a call to svg circle elelent :: create function. The code in 
> the svg file was :
> 
> 
>  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";> 
>  xmlns="http://www.w3.org/2000/svg";> 
>fill="red"/>
> 
> 
> I am confused now and want to know what is the main difference between the 
> two projects. One idea is that minibrowser is using webkit2 instead of 
> webkit. Even if that is the case, I think svg call should still be there if 
> the main difference between webkit2 and webkit is only of the processes.

I assume by trace you mean debug, in which case my understanding is that you're 
looking at the wrong process in WebKit2. Minibrowser is the UI process which 
will never execute the SVG ::create method. You need the Web process. The 
Chrome browser does something similar.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] New feature enabled - ANIMATION_API

[Dean Jackson]

It is with some reluctance that I inform this list of a new ENABLE option: 
ANIMATION_API. I realise we are supposed to be removing these, not adding :(

Basically the feature is a scripting interface to CSS animations and 
potentially SMIL/SVG. It doesn't do much at the moment but will eventually 
allow you to query for all the running animations, pause and scrub the 
timeline, and create keyframes without going through the CSS OM (yuck!). It 
also needs to play nicely with the new requestAnimationFrame method.

Why a feature? Since it is a work-in-progress and does not have an official 
standard behind it (we plan to submit it once baked), it would be bad if 
official browser releases exposed something that people might start to use or 
test for. This allows an implementation to hide the DOM API. The actual 
implementation is still present.

It is disabled by default. Before I added the ENABLE, it was visible in trunk 
and nightly builds.

If you have any comments on the API in its very early stages, please contact me 
or send to public...@w3.org.

Dean



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

Dirk (known in these parts as krit) reminded me that I had not emailed 
webkit-dev about the plans to start an implementation of W3C's new Filter 
Effects specification. 

https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html

The quick summary is that this exposes the 'filter' property from SVG to 
everything in CSS, and adds some shorthands for common effects so people don't 
have to write XML in order to do something like a blur or sepia effect. The 
spec has received a fair amount of input from the CSS and SVG working groups, 
and particularly from Apple, Google, Mozilla, Opera and Adobe.

Here's the tracking bugzilla:

https://bugs.webkit.org/show_bug.cgi?id=68469

It will be protected by the existing ENABLE(FILTERS), unless someone has a good 
reason why this should be a new enabled feature name.

The implementation plan that I have in mind is:

- start with '-webkit-filter' only for HTML elements that supports something 
similar to the existing 'filter'
- implement more of the spec, including the shorthands
- expose '-webkit-filter' to SVG, but only if the existing 'filter' property is 
not set
- wait for the spec to progress, then drop the prefix

In parallel we'll also be looking at animation of these effects, plus hardware 
acceleration (open questions to how: OpenCL? Graphics3D? Core Image where 
available?)

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

On 23/09/2011, at 4:38 AM, Eric Seidel wrote:

> I was actually considering removing ENABLE(FILTERS) since it seemed to
> be on everywhere.

Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on 
desktop and iOS. 

>  It would probably be better for us to remove it
> first and this feature to exist under its own define (if it even needs
> a define?).
> 
> If you'll want folks to be able to turn this off w/o affecting their
> existing shipping configurations, you'd need a new define.  But I'm
> also not sure anyone will need to turn it off.  I leave that up to
> you. :)

I don't mind either way. I'll take this message as a suggestion to
add a new define, at least for the moment.

Dean

> 
> -eric
> 
> On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson  wrote:
>> Dirk (known in these parts as krit) reminded me that I had not emailed 
>> webkit-dev about the plans to start an implementation of W3C's new Filter 
>> Effects specification.
>> 
>> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
>> 
>> The quick summary is that this exposes the 'filter' property from SVG to 
>> everything in CSS, and adds some shorthands for common effects so people 
>> don't have to write XML in order to do something like a blur or sepia 
>> effect. The spec has received a fair amount of input from the CSS and SVG 
>> working groups, and particularly from Apple, Google, Mozilla, Opera and 
>> Adobe.
>> 
>> Here's the tracking bugzilla:
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=68469
>> 
>> It will be protected by the existing ENABLE(FILTERS), unless someone has a 
>> good reason why this should be a new enabled feature name.
>> 
>> The implementation plan that I have in mind is:
>> 
>> - start with '-webkit-filter' only for HTML elements that supports something 
>> similar to the existing 'filter'
>> - implement more of the spec, including the shorthands
>> - expose '-webkit-filter' to SVG, but only if the existing 'filter' property 
>> is not set
>> - wait for the spec to progress, then drop the prefix
>> 
>> In parallel we'll also be looking at animation of these effects, plus 
>> hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image 
>> where available?)
>> 
>> Dean
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit

[Dean Jackson]

On 23/09/2011, at 5:59 AM, Ian Hickson wrote:

> On Thu, 22 Sep 2011, Charles Pritchard wrote:
>> 
>> Regardless of an ENABLE flag, be certain to use the webkit prefix.
>> document.getItems(typeNames) turns into
>> document.webkitGetItems(typeNames)
>> 
>> Note that it's easy to implement this in pure javascript as a prototype.
> 
> Assuming the patch implements the spec correctly, no need to use a prefix 
> -- I'll track the implementations and ensure no conflicts.

That's an interesting approach to prefixing - I commend the volunteering
of your time. 

However, isn't prefixing designed to avoid incompatibilities in spec
changes, not incompatibilities between implementations? Ensuring no
conflicts in implementations doesn't matter too much if the spec changes.

Note I'm not talking about Microdata in particular. I don't even know
what that spec is :) I'm just talking about the general approach. If
the world can guarantee that this spec will never change, then I guess
your technique works.

FWIW, there is an in-between approach, which is the one used by
WebGL. It defines a prefix that all implementations share.

canvas.getContext("experimental-webgl");

Dean



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

Hey Dirk,

On 23/09/2011, at 6:24 AM, Dirk Schulze wrote:

> Dean, do you want to reuse the existing filter code, or do you plan to write 
> another filter implementation just for CSS? Would be interesting if we would 
> need to nest CSS_FILTERS and FILTERS, or if they could get enabled 
> independent of each other.

I plan to use the existing filter code. It's nicely neutral of SVG. This would 
mean that CSS_FILTERS does require FILTERS, but I could also change the #ifs to 
use ||. 

BTW - the Filter Effects specification (ENABLE_CSS_FILTERS) does support "What 
was previously known as SVG Filters" (ENABLE_FILTERS), so there is a dependency.

When hardware acceleration comes we'll obviously begin diverging. As you 
mentioned elsewhere, buried in the depths of SVN is a Core Image-based version.

> Like previous comments mention, Apple still does not enable SVG Filters for 
> Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it 
> would force FILTERS to get enabled as well.

That's right. This new specification is mostly adding some new syntax and 
exposing filters to HTML/CSS.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

On 22/09/2011, at 11:30 AM, Dean Jackson wrote:

> Dirk (known in these parts as krit) reminded me that I had not emailed 
> webkit-dev about the plans to start an implementation of W3C's new Filter 
> Effects specification. 
> 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
> 
> The quick summary is that this exposes the 'filter' property from SVG to 
> everything in CSS, and adds some shorthands for common effects so people 
> don't have to write XML in order to do something like a blur or sepia effect. 
> The spec has received a fair amount of input from the CSS and SVG working 
> groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.

A followup: we're going to start work on the CSS Shaders proposal [1] soon. 
Adobe have published their implementation which was specific to Chromium, and 
we'll be working with them to split it into small patches that can land in the 
coming weeks. A good introduction to the technology is [2].

This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards 
for ENABLE_WEBGL since the implementation (and security) requirements are so 
similar.

Dean

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
[2] www.adobe.com/devnet/html5/articles/css-shaders.html


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 24/10/2011, at 9:08 PM, Adam Barth wrote:

> How have you solved the security problems with CSS Shaders?
> Specifically, timing attacks can be used to extract image information
> passed to shaders and many things WebKit renders are sensitive and
> should not be exposed to the web site (e.g., the color of visited
> links).

This is a good question and I know that I don't have the answers (and can't 
even claim to understand all the implications).

I think the most important restriction is that shaders should not apply 
cross-origin. e.g. iframes and probably anything with  children from 
another domain (unless it is marked as ok via CORS).

The possibility of leaking information such as visited links, or maybe 
reconstructing text which could be fed to OCR, is more difficult. Is this 
really specific to CSS Shaders? SVG filters would theoretically be able to do 
the same thing. In fact, given enough knowledge of WebKit rendering one could 
imagine tweaking the style of an element in a way that causes a measurable 
rendering slowdown.

I'd like to know what the actual threat of such timing attacks are. I've seen 
claims of a maximum theoretical leak rate (in bits/s) but then counter claims 
that since, in this case, it would be hard to distinguish the difference in 
slowdown between CSS shaders and general page rendering, that the real rate is 
much lower. And, at least in the case of Safari, you can't always be sure that 
getting a rAF callback means you're about to draw.

Does anyone have hard data on this?

Dean



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 25/10/2011, at 3:13 AM, Dirk Schulze wrote:

>>> I'd like to know what the actual threat of such timing attacks are. I've 
>>> seen claims of a maximum theoretical leak rate (in bits/s) but then counter 
>>> claims that since, in this case, it would be hard to distinguish the 
>>> difference in slowdown between CSS shaders and general page rendering, that 
>>> the real rate is much lower. And, at least in the case of Safari, you can't 
>>> always be sure that getting a rAF callback means you're about to draw.
>>> 
>>> Does anyone have hard data on this?
>> 
>> At a minimum, please do not land an implementation for this feature
>> without a way for ports that are concerned about this security feature
>> to disable it independently of both CSS_FILTERS and WEBGL.  Contrary
>> to your previous assertion, the security implications are quite
>> different than those with WebGL.

Sorry, I was assuming a WebGL that allowed input from 
canvasContext.drawElement. At that point I think they are close enough to call 
the same (no doubt I'm wrong! :) Even without drawElement, WebGL offers a lot 
of attack vectors.

> We already discussed the HW acceleration of SVG Filters on 
> https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS 
> Filters earlier on this mailing list. We agreed that we will continue to use 
> the implemented software rendering as fallback for Filters. CSS Shaders won't 
> be included. Shaders should just be supported if HW acceleration is enabled. 
> And I think as a minimum consensus on bug 70099 most people on the thread 
> agreed to go on with GraphicsContext3D for now. In my opinion it means we 
> would have the same security concerns like on WebGL. That's also one reason 
> why I think that the WEBGL flag would match these needs quite well, even if 
> CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS 
> Shaders are deactivated (and ignored if web developers use them in their 
> filter chain) and Filters take the software rendering fallback.

Adam's point in the bug is that any operation that can access colour channels 
might be able to perform a timing attack. This would include SVG filters 
operating on HTML content without any hardware acceleration.

For this reason I'm still tempted to suggest the combination of CSS_FILTERS + 
WEBGL is enough of a switch for ports to disable this, but I'm happy to add 
another one.

I'm not sure at what point we should take the discussion from this list and 
onto bugzilla.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 25/10/2011, at 9:49 AM, Adam Barth wrote:

>> Adam's point in the bug is that any operation that can access colour 
>> channels might be able to perform a timing attack. This would include SVG 
>> filters operating on HTML content without any hardware acceleration.
>> 
>> For this reason I'm still tempted to suggest the combination of CSS_FILTERS 
>> + WEBGL is enough of a switch for ports to disable this, but I'm happy to 
>> add another one.
>> 
>> I'm not sure at what point we should take the discussion from this list and 
>> onto bugzilla.
> 
> I don't believe you understand the security issue.  I'd recommend you
> seek the advice of security experts to help you make this decision.

OK, I'll make sure CSS Shaders has a separate flag which allows ports to turn 
it off. But you'll still be susceptible to the same problems with CSS_FILTERS, 
and with the current implementation of SVG filters that you support.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dean Jackson]

On 24/10/2011, at 9:02 PM, Dean Jackson wrote:

> 
> On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
> 
>> Dirk (known in these parts as krit) reminded me that I had not emailed 
>> webkit-dev about the plans to start an implementation of W3C's new Filter 
>> Effects specification. 
>> 
>> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
>> 
>> The quick summary is that this exposes the 'filter' property from SVG to 
>> everything in CSS, and adds some shorthands for common effects so people 
>> don't have to write XML in order to do something like a blur or sepia 
>> effect. The spec has received a fair amount of input from the CSS and SVG 
>> working groups, and particularly from Apple, Google, Mozilla, Opera and 
>> Adobe.
> 
> A followup: we're going to start work on the CSS Shaders proposal [1] soon. 
> Adobe have published their implementation which was specific to Chromium, and 
> we'll be working with them to split it into small patches that can land in 
> the coming weeks. A good introduction to the technology is [2].
> 
> This will be done behind the ENABLE_CSS_FILTERS macro, but also with the 
> guards for ENABLE_WEBGL since the implementation (and security) requirements 
> are so similar.

As requested by Adam, this is now ENABLE_CSS_SHADERS and landed yesterday:

http://trac.webkit.org/changeset/99118

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

[Dean Jackson]

On 04/12/2011, at 6:06 PM, Adam Barth wrote:

> On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth  wrote:
>> Personally, I don't believe it's possible to implement this feature
>> securely, at least not using the approach prototyped by Adobe.
>> However, I would love to be proven wrong because this is certainly a
>> powerful primitive with many use cases.
> 
> I spent some more time looking into timing attacks on CSS Shaders.  I
> haven't created a proof-of-concept exploit, but I believe the current
> design is vulnerable to timing attacks.  I've written up blog post
> explaining the issue:
> 
> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html

Thanks for writing this up.

I'm still interested to know what the potential rate of data leakage is.
Like I mentioned before, there are plenty of existing techniques that could
expose information to a timing attack. For example, SVG Filters can
manipulate the color channels of cross-domain images, and using CSS overflow
on an iframe could potentially detect rendering slowdowns as particular
colors/elements/images come into view. CSS shaders increase the rate of leakage
because they execute fast and can be tweaked to exaggerate the timing, but
one could imagine that the GPU renderers now being used in many of WebKit's 
ports
could be exploited in the same manner (e.g. discover a CSS "trick" that drops
the renderer into software mode).

Obviously at a minimum we'll need to be careful about cross-domain content,
and give input to filters (not just CSS shaders, and moz-element or 
ctx2d.drawElement)
that doesn't expose user info like history. 

But I wonder if there is also some more general approach to take here.
You mention Mozilla's paint events and requestAnimationFrame. Without those
it would be much more difficult to get timing information. The original
exploit on WebGL was especially easy because you could explicitly time a
drawing operation. This is more difficult with CSS (and in Safari, we
don't necessarily draw on the same thread, so even rAF data might not
be accurate enough).

Is there something we can do to make rendering-based timing attacks
less feasible?

Here's a idea I heard floated internally: since the rAF-based attack would be
trying to trigger cases where the framerate drops from 60fps to 30fps, is
there some way we can detect this and do something about it? For example,
once you drop, don't return to 60fps for some random amount of time even if
it is possible. This might sound annoying to developers, but I expect anyone
legitimately concerned with framerate is going to want to do what they can
to keep at the higher value (i.e. they'll want to rewrite their code to
avoid the stutter). This doesn't stop the leak, but it slows it down. And as
far as I can tell everything is leaky - we're just concerned about the
rate. I know there won't be a single solution to everything.

Or maybe rAF is inherently insecure?

Dean



> 
> Jonas Sicking seems to have a similar concern:
> 
> https://twitter.com/#!/SickingJ/status/143161375823380480
> 
> It's probably worth addressing this concern sooner rather than later.
> Ignoring it certainly won't cause the vulnerability to go away.
> 
> Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ProgressEvents for Images

[Dean Jackson]

On 17/01/2012, at 10:41 AM, Bear Travis wrote:

> A group of us at Adobe has been looking into adding support for 
> ProgressEvents 
> to images.  The overall goal is to simplify image download progress reporting 
> by supporting roughly the same progress events as XHR and the File API for 
> image elements.   For example one could connect an image to a progress 
> element 
> like this:
> 
>  onloadstart="showProgressBar()"
> onprogress="updateProgressBar(event)"
> onloadend="hideProgressBar()"/>
> 
> Developers have taken various tacks to enable progress reporting, for example 
> in some cases XHR can be used to download image files.  Max Vujovic just 
> published a blog about the practicalities of doing so: 
> http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.  We 
> think it would be preferable to provide support for image progress events 
> directly.

I think this would be extremely useful. It would require a proposal to
W3C or WHATWG though.

Dean

> 
> We're working on a prototype implementation for WebKit and have filed a bug 
> that explains what we're up to in a little more detail: 
> https://bugs.webkit.org/show_bug.cgi?id=76102
> 
> It's probably worth pointing out that the beforeload event, which is 
> currently 
> under discussion, addresses a different use case.  Our proposal is intended 
> to 
> enable applications to give the user feedback about image download progress, 
> it's not intended to enable security or efficiency by preemptively blocking 
> or 
> transforming image downloads.
> 
> We'd appreciate feedback on this proposal.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Anyone using NEON code on ARM builds?

[Dean Jackson]

Hi,

There are three files with embedded NEON code to speed up filters:

./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}

Are any ARM ports using this? (would require SVG and FILTERS both enabled) If 
so, could you contact me? Off list is fine.

I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg. 
https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very slightly 
touched for some chromium build issues.

Thanks,

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Anyone using NEON code on ARM builds?

[Dean Jackson]

Hi Jonathan,

On 21/03/2012, at 12:56 AM, Jonathan Kliegman wrote:

> On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson  wrote:
> Hi,
> 
> There are three files with embedded NEON code to speed up filters:
> 
> ./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
> 
> Are any ARM ports using this? (would require SVG and FILTERS both enabled) If 
> so, could you contact me? Off list is fine.
> 
> I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg. 
> https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very slightly 
> touched for some chromium build issues.
> 
> Chrome OS has ports that use NEON and has SVG and FILTERS both enabled so 
> this would still be used.

Excellent!

Zoltan and I have been chatting offline a bit. I was testing compilation on 
Darwin/iOS ARM and running into a few issues. The first was about alignment 
errors from the compiler. The second was some linking issues, for example:

> https://bugs.webkit.org/show_bug.cgi?id=81568

Is there someone (you?) on the Chrome team I should CC on any bugs raises?

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 10:07 AM, Annie Sullivan  wrote:

> Oops, forgot to reply-all.
> 
> On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan  wrote:
>> On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler  wrote:
>>> 
>>> Our past experience with this sort of thing at Apple is that it led to bugs 
>>> we didn’t find until after we shipped “final” software because they did not 
>>> show up during earlier testing. Since then, we’ve gone out of our way to 
>>> avoid differences, since one of the main things we want to do with 
>>> non-final builds is to approximate the final releases as closely as 
>>> possible to get useful testing.
>>> 
>>> To oversimplify, website developers notoriously make mistakes with these 
>>> types of attributes doing things like version and OS checks, leading to 
>>> website incompatibilities.
>> 
>> Yes, this is definitely a concern we have as well.
>> 
>>> Maybe you could make your case for the usefulness of the attribute?
>> 
>> The problem we're experiencing in Chrome is for sites that collect
>> usage data--it turns out there's a selection bias caused by users who
>> opt in to our canary, dev, and beta channels.
>> 
>> The specific case I'm looking at right now is sites collecting
>> performance data from their user base. We'd love for these sites to be
>> able to report regressions they see in Chrome's performance as early
>> as possible. But it turns out users on different channels actually
>> show different performance characteristics. Beta users seem to have
>> faster machines, for example. So in order to compare two versions of
>> Chrome, we need to compare data from users on the same release
>> channel. So we'd like sites who collect performance information to be
>> able to collect the build type in order to do that comparison.
>> 
>> We considered a few alternatives:
>> 1) Adding a marker in the user agent string that indicates the
>> channel. The problem with this is that there is a lot of very fragile
>> code in the wild which parses user agent strings and breaks at the
>> slightest change. For example, code that parses Opera 10 as Opera 1.
>> 2) Updating the version number as Chrome advances from canary to dev
>> to beta to stable, or encoding the build type in one of the octets of
>> the version number. The problem with this is that there's a big
>> possibility of sites that do version checking accidentally turning off
>> features on some channels. There are also a lot of things that we *do*
>> want to track across release channels for a specific version, like
>> bugs. So changing the version number could cause confusion there.
>> 3) Sending an "x-buildtype" header. If we do this on every request,
>> it's a lot of bloat. We can't restrict it to requests that send a
>> corresponding "x-tell-me-the-buildtype" request header because most
>> metrics collection libraries send their metrics in an image request,
>> so they can't send custom headers.

navigator.buildType might address your particular problem, but introduces a 
significant risk of future issues. I can imagine keen web authors adding 
features based on detecting "nightly" or "beta" that then break in "final".

This is similar to prefixing CSS properties which, as you probably know, is an 
extremely hot discussion topic right now in the community. I don't think people 
will be especially excited for another potential point of failure.

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 12:05 PM, Annie Sullivan  wrote:

> In many browsers in the past, it's been
> pretty easy to determine from "a" and "b" characters in the user agent
> of many browsers which builds are "alpha" and "beta", and I haven't
> heard of bugs caused specifically by checking for build type there.

So why not just do that then?

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 12:53 PM, Annie Sullivan  wrote:

> On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson  wrote:
>> 
>> On 07/06/2012, at 12:05 PM, Annie Sullivan  wrote:
>> 
>>> In many browsers in the past, it's been
>>> pretty easy to determine from "a" and "b" characters in the user agent
>>> of many browsers which builds are "alpha" and "beta", and I haven't
>>> heard of bugs caused specifically by checking for build type there.
>> 
>> So why not just do that then?
> 
> While it's nice that web developers don't seem to be using the build
> type info in the user agent string in their code, user agent parsing
> code is still very brittle. Some browsers, like Firefox, have had
> buildtype characters in the user agent string for many years, so
> parsing code can handle things like "Firefox/14.0a2". But Chrome
> hasn't ever changed its version format, so we're worried about
> breaking user agent parsers.

Right, I understand that issue. But I don't think replacing something
flakey and problematic with something that could be equally flakey and
problematic is a big win.

Your original problem was:

> We'd love for these sites to be able to report regressions they see in 
> Chrome's performance as early as possible. But it turns out users on 
> different channels actually show different performance characteristics. Beta 
> users seem to have faster machines, for example. So in order to compare two 
> versions of Chrome, we need to compare data from users on the same release 
> channel. So we'd like sites who collect performance information to be able to 
> collect the build type in order to do that comparison.

That sounds exactly like User Agent detection to me. You want
to detect build version and type.

I still think there are similarities to prefixing. The Web community
(not just WebKit) is making a lot of noise about how being able to
detect browsers might seem like a good idea at first but ends up
causing longer-term headaches.

By the way, I don't feel strongly about this. I'm just pointing
out that I don't see any benefit and that what looks like a
small change in metadata has just as important consequences
as a significant technical change.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore

[Dean Jackson]

On 07/06/2012, at 1:10 PM, Adam Barth  wrote:

> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa  wrote:
>> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan 
>> wrote:
>>> 
>>> I wanted to let you know that I plan to add support for
>>> navigator.buildType (e.g., "nightly", "beta", "final") to WebKit. This
>>> feature isn't on the standards track (but neither are a bunch of other
>>> similar properties on Navigator). This feature will be behind the
>>> ENABLE(NAVIGATOR_BUILDTYPE) feature define. See:
>>> https://bugs.webkit.org/show_bug.cgi?id=88358
>>> http://html.spec.whatwg.org/#navigator
>> 
>> What is the rationale for adding this property on the navigator object
>> instead of the chrome object we also expose if your'e not expecting this
>> property to be ever standarized?
> 
> Generally, we avoid implementing web visible features via the "chrome"
> object because that makes them Chrome-proprietary.  In this case, it
> seems entirely reasonable for other browsers (e.g., Firefox) to want
> to implement this feature.  By putting it on navigator, we invite them
> to implement it as well.

But the original message said:

> I wanted to let you know that I plan to add support for navigator.buildType 
> (e.g., "nightly", "beta", "final") to WebKit. This feature isn't on the 
> standards track (but neither are a bunch of other similar properties on 
> Navigator)

If you don't want it to be Chrome or WebKit-proprietary, and you're inviting 
other browsers to implement it, then you should probably speak to them and the 
rest of the community up front.

It definitely would be much nicer if User Agent was exposed as a bunch of 
neatly organised JavaScript properties on the navigator object. Of course then 
we'd eventually have issues similar to what are now parsing errors. Who says a 
browser won't want to add "alpha" or "release-candidate" to the list above. 
This is going to be flakey no matter what.

I should stop replying now because I really don't care anywhere near as much 
about this as I'm suggesting by all my email :)

Dean


> 
>> The feedback the WebKit community at large has given us so far appears to be
>> strictly negative about adding this to the navigator object.
> 
> The mechanism for implementing the feature doesn't really affect the
> arguments that folks are making on this thread.  If we decide that the
> feature is worth implementing, we should implement it on navigator.
> If the feature is not worth implementing, we shouldn't implement it on
> the "chrome" object either.
> 
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Delaying Applying CSS Effects

[Dean Jackson]

On 25/07/2012, at 6:09 AM, Keyar Hood  wrote:

> I am working on https://bugs.webkit.org/show_bug.cgi?id=90405
> 
> The problem is that when doing SVG filters in CSS using URL references, if 
> the target SVG filter is after the element that the filter is to be applied 
> to (the filtered element), then the filter will not be applied.
> 
> Looking at the code, a getElementByID() call is made when looking for the 
> target SVG filter. However, this does not work when the target SVG filter is 
> after the filtered element. I believe this is because the DOM element for the 
> target SVG filter does not exist yet.
> 
> I am wondering if there is some way to delay resolving these CSS effects 
> until after the DOM has finished loading.

Your analysis sounds right. I think we'll have to do exactly that: delay 
calling buildFilterEffectRenderer until the document has loaded.

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] support for svg handler element

[Dean Jackson]

On 10/01/2010, at 1:27 AM, nagarjuna atluri wrote:

> Hai all,
> 
> Is handler element for svg supported in webkit..
> can anyone help me out..

If you're talking about the XML Events  element that
is mentioned in SVG 1.2, then the answer is no - it isn't supported.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Support for SVG preserveAspectRatio in

[Dean Jackson]

Hi Leif,

Yes, this is a bug. Please file it, thanks!

Dean

On 02/02/2010, at 8:17 AM, Leif Arne Storset wrote:

> Hello,
> 
> While doing some SVG-related work over here I discovered that WebKit's
> rendering of SVG in  tags differs from Opera's. Since WebKit and
> Opera to my knowledge are the only engines that currently support SVG in
>  we thought it would be worthwhile to make sure we are compatible.
> 
> As far as I can tell from the latest nightly builds (and the latest Chrome
> release on Linux), WebKit will render an SVG in  much like a bitmap:
> it will resolve the width and height of the image and stretch it to fill
> the content box. It will respect any viewbox (presumably synthesizing one
> if it is missing), but preserveAspectRatio [1] seems not to be applied to
> an SVG in , and the default rendering (whether there is a viewbox or
> not) is as if preserveAspectRatio="none".
> 
> Opera (Presto engine) will also resolve image dimensions and synthesize
> missing viewboxes, and will synthesize a viewBox if it can, as outlined
> in SVG WG ISSUE-2258 [2], and applies preserveAspectRatio as specified in
> SVG 1.1 (note that pAR has a default value 'xMidYMid meet'). The viewBox
> (whether specified or synthetic) are used together with pAR when rendering
> the SVG into the viewport established by the  element.
> 
> The attached images and test case illustrate the two renderings.
> 
> A quick Google search of webkit.org revealed little on preserveAspectRatio
> except a reference to a 2008 bug in SVGImageElement. However, for
>  (that is:  elements inside of an ), pAR seems to
> be applied as per the spec.
> 
> We believe that not applying the pAR on svg in  means that WebKit
> has invalid rendering behaviour according to the SVG 1.1 specification.
> 
> To enhance cross-browser compatibility it would be good if WebKit also
> considered synthesizing viewBoxes as outlined in [2], as this makes it
> easier to reuse existing svg content created by svg editors such as
> Inkscape (such content most often has a width and height, but lacks a
> viewBox).
> 
> I hope you find these recommendations useful. Please let me know if I can
> be of further assistance. If desired I can file a bug in your issue
> tracker.
> 
> -- 
> Leif Arne Storset
> Layout developer, Opera Software
> 
> [1] http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute
> [2] 
> http://www.w3.org/Graphics/SVG/WG/track/issues/2258___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] DeviceOrientation/Motion on Document rather than Page

[Dean Jackson]

Hi,

I've been looking into implementing the clients for DeviceOrientation/Motion 
Events. Currently, the controllers for these events are members of Page. I 
think they are better suited on Document.

Here are a few reasons:

- Page isn't tied to any actual web page or document. Would we want to share 
the same controller and client across multiple web pages? I don't think so.
- Document is already the place that is listening for these events
- It's easy to suspend and resume the client from the Document-level when the 
user navigates to another page, or the document enters the cache, or a platform 
needs to temporarily suspend events for some reason.
- When the API is on Page, it is hidden in the WebView, from where it is 
difficult to access.
- it would allow the client to live in WebCore. This avoids tweaking the 
WebView implementations for all platforms to pass messages back and forth
https://bugs.webkit.org/show_bug.cgi?id=41616

I assume one of the advantages of having them on Page is that it allows a Mock 
Controller to be easily created for testing from Dump Render Tree. Am I right? 
Is this that important?

FWIW, Geolocation seems to take both approaches. One implementation is down in 
Navigator/Document/DOMWindow, but the mock controller is on Page. I've found 
the low-level approach much easier to implement.

Thoughts?

Dean



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] null clients of Page

[Dean Jackson]

It was suggested I bring this to webkit-dev.

There was some recent work to move the many parameters passed to the Page 
constructor into a single PageClients structure. The current assumption is that 
if a feature is enabled (at runtime or compile time) then Page will always get 
a non-null client for that feature.

This allows the Page constructor to have something like this:

, m_deviceMotionController(RuntimeEnabledFeatures::deviceMotionEnabled() ? n
ew DeviceMotionController(pageClients.deviceMotionClient) : 0)

and DeviceMotionController's constructor has an ASSERT(m_client).

The problem is that not every Page needs every client. SVGImage, for example, 
creates a Page without all clients. Some platform ports branch around this 
code. The current solution is to create EmptyClient implementations.

https://bugs.webkit.org/show_bug.cgi?id=43848
https://bugs.webkit.org/show_bug.cgi?id=43533

Related discussion: 
https://lists.webkit.org/pipermail/webkit-dev/2010-July/013597.html

Wouldn't it be easier to allow null clients than to have these EmptyClient 
implementations? 

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] null clients of Page

[Dean Jackson]

On 16/08/2010, at 11:35 PM, Darin Fisher wrote:

> > Wouldn't it be easier to allow null clients than to have these EmptyClient 
> > implementations?
> 
> Dean
> 
> 
> I think that'd be a lot of null checks.  It seems like it could add a fair 
> bit of code throughout WebCore, and folks would have to be careful not to 
> forget any null checks.
> 

Fair enough. I was just trying to avoid the branching before the Page is 
constructed, but you're right. (If I can move DeviceMotion to Document, it 
might not need anything on Page anyway)

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page

[Dean Jackson]

On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:

> 
> On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
> 
>> Where-ever it goes, please don't put it on Document directly. :)
>> (Feel free to tie it to Document's lifetime, just don't add to
>> Document's 300+ methods.)
>> 
>> The madness must stop...  Document is long overdue for some weightloss...
> 
> I assume Dean is suggesting that Document would gain a new data member 
> (DeviceMotionController?) which strikes me as a reasonable approach.

Right - either one or two (+DeviceOrientationController). I do think the 
controllers of both events could be a single object - but that is another 
discussion.

If it wasn't on Document, what do you suggest otherwise? DOMWindow? Putting it 
on Frame but tying it to Document seems less than perfect.

Dean

> 
>> 
>> -eric
>> 
>> On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson  wrote:
>>> Hi,
>>> 
>>> I've been looking into implementing the clients for 
>>> DeviceOrientation/Motion Events. Currently, the controllers for these 
>>> events are members of Page. I think they are better suited on Document.
>>> 
>>> Here are a few reasons:
>>> 
>>> - Page isn't tied to any actual web page or document. Would we want to 
>>> share the same controller and client across multiple web pages? I don't 
>>> think so.
>>> - Document is already the place that is listening for these events
>>> - It's easy to suspend and resume the client from the Document-level when 
>>> the user navigates to another page, or the document enters the cache, or a 
>>> platform needs to temporarily suspend events for some reason.
>>> - When the API is on Page, it is hidden in the WebView, from where it is 
>>> difficult to access.
>>> - it would allow the client to live in WebCore. This avoids tweaking the 
>>> WebView implementations for all platforms to pass messages back and forth
>>> https://bugs.webkit.org/show_bug.cgi?id=41616
>>> 
>>> I assume one of the advantages of having them on Page is that it allows a 
>>> Mock Controller to be easily created for testing from Dump Render Tree. Am 
>>> I right? Is this that important?
>>> 
>>> FWIW, Geolocation seems to take both approaches. One implementation is down 
>>> in Navigator/Document/DOMWindow, but the mock controller is on Page. I've 
>>> found the low-level approach much easier to implement.
>>> 
>>> Thoughts?
> 
> For this sort of thing, it seems reasonable to me that there is a layer of 
> the implementation that is a per-document controller, and then below that a 
> singleton object in case we don't need things to happen multiple times per 
> document. It doesn't seem especially helpful to have something happen at the 
> Page level, in normal operation.
> 
> The reason it seems a singleton would be useful is that you only want to 
> register with the OS service once, and then multicast the relevant 
> notifications to all clients that are listening.
> 
> For purposes of substituting a mock controller:
> 
> (1) If there is a singleton beneath the per-document controllers, perhaps the 
> mock object can insert itself at that level.
> (2) Even if the mock controller is at the per-document level, it is likely 
> still sufficient for most tests; it might mean a little extra work if we need 
> to specifically test geolocation or device motion/orientation from a subframe.
> 
> Regards,
> Maciej
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page

[Dean Jackson]

On 17/08/2010, at 7:21 AM, Eric Seidel wrote:

> My apologies for derailing your earlier discussion.  I just was in
> Document.cpp again yesterday and my mind was blown by the madness that
> is that god-class.  Then you posted about adding to Document (which
> sounds like the right corse of action here!) and I took advantage of
> your post for my stop-pooping-on-Document PSA.
> 
> I too have 100% confidence in Dean here. :)  As Maciej says, it's just
> a controller on Document.

Congratulations on being the first person to ever have confidence in me :)

I too would like to know how to reorganise Document better. It is HUGE. Seeing 
as you are discussing similar topics on IRC with EricC, maybe now is the time 
to bring it up.

Dean

> 
> Carry on.
> 
> -eric
> 
> On Tue, Aug 17, 2010 at 8:50 AM, Dean Jackson  wrote:
>> 
>> On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
>> 
>>> 
>>> On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
>>> 
>>>> Where-ever it goes, please don't put it on Document directly. :)
>>>> (Feel free to tie it to Document's lifetime, just don't add to
>>>> Document's 300+ methods.)
>>>> 
>>>> The madness must stop...  Document is long overdue for some weightloss...
>>> 
>>> I assume Dean is suggesting that Document would gain a new data member 
>>> (DeviceMotionController?) which strikes me as a reasonable approach.
>> 
>> Right - either one or two (+DeviceOrientationController). I do think the 
>> controllers of both events could be a single object - but that is another 
>> discussion.
>> 
>> If it wasn't on Document, what do you suggest otherwise? DOMWindow? Putting 
>> it on Frame but tying it to Document seems less than perfect.
>> 
>> Dean
>> 
>>> 
>>>> 
>>>> -eric
>>>> 
>>>> On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson  wrote:
>>>>> Hi,
>>>>> 
>>>>> I've been looking into implementing the clients for 
>>>>> DeviceOrientation/Motion Events. Currently, the controllers for these 
>>>>> events are members of Page. I think they are better suited on Document.
>>>>> 
>>>>> Here are a few reasons:
>>>>> 
>>>>> - Page isn't tied to any actual web page or document. Would we want to 
>>>>> share the same controller and client across multiple web pages? I don't 
>>>>> think so.
>>>>> - Document is already the place that is listening for these events
>>>>> - It's easy to suspend and resume the client from the Document-level when 
>>>>> the user navigates to another page, or the document enters the cache, or 
>>>>> a platform needs to temporarily suspend events for some reason.
>>>>> - When the API is on Page, it is hidden in the WebView, from where it is 
>>>>> difficult to access.
>>>>> - it would allow the client to live in WebCore. This avoids tweaking the 
>>>>> WebView implementations for all platforms to pass messages back and forth
>>>>> https://bugs.webkit.org/show_bug.cgi?id=41616
>>>>> 
>>>>> I assume one of the advantages of having them on Page is that it allows a 
>>>>> Mock Controller to be easily created for testing from Dump Render Tree. 
>>>>> Am I right? Is this that important?
>>>>> 
>>>>> FWIW, Geolocation seems to take both approaches. One implementation is 
>>>>> down in Navigator/Document/DOMWindow, but the mock controller is on Page. 
>>>>> I've found the low-level approach much easier to implement.
>>>>> 
>>>>> Thoughts?
>>> 
>>> For this sort of thing, it seems reasonable to me that there is a layer of 
>>> the implementation that is a per-document controller, and then below that a 
>>> singleton object in case we don't need things to happen multiple times per 
>>> document. It doesn't seem especially helpful to have something happen at 
>>> the Page level, in normal operation.
>>> 
>>> The reason it seems a singleton would be useful is that you only want to 
>>> register with the OS service once, and then multicast the relevant 
>>> notifications to all clients that are listening.
>>> 
>>> For purposes of substituting a mock controller:
>>> 
>>> (1) If there is a singleton beneath the per-document controllers, perhaps 
>>> the mock object can insert itself at that level.
>>> (2) Even if the mock controller is at the per-document level, it is likely 
>>> still sufficient for most tests; it might mean a little extra work if we 
>>> need to specifically test geolocation or device motion/orientation from a 
>>> subframe.
>>> 
>>> Regards,
>>> Maciej
>>> 
>> 
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page

[Dean Jackson]

On 23/08/2010, at 9:14 PM, Steve Block wrote:

>> - it would allow the client to live in WebCore.
>> FWIW, Geolocation seems to take both approaches. One implementation is down 
>> in Navigator/Document/DOMWindow,
>> but the mock controller is on Page. I've found the low-level approach much 
>> easier to implement.
> My understanding was that clients for these platform-specific features
> should live in the WebKit layer. The original Geolocation
> implementation used a platform-specific GeolocationService in WebCore,
> but a client-based implementation was later added by Sam to avoid the
> layering violations of the former approach. See
> https://bugs.webkit.org/show_bug.cgi?id=32499#c10.
> 
> I'm currently working to remove the old non-client-based Geolocation
> implementation, see https://bugs.webkit.org/show_bug.cgi?id=40373.
> Please let me know if this is the wrong approach!
> 
>> I assume one of the advantages of having them on Page is that it allows a 
>> Mock Controller to be easily created
>> for testing from Dump Render Tree. Am I right? Is this that important?
> Yes, that is also part of the motivation. The non-client-based
> Geolocation implementation provides a mock in WebCore, but setting and
> configuring this mock from DumpRenderTree is ugly.

I'd rather the mock controller setup be ugly than the typical use of the 
controller. Having the controller and client on Page was quite annoying. I'd 
much prefer it lived on Document.

Is there some way we can combine the two?

Dean

> 
>> For this sort of thing, it seems reasonable to me that there is a layer of 
>> the implementation that is a per-document
>> controller, and then below that a singleton object in case we don't need 
>> things to happen multiple times per document.
> I don't have a strong opinion regarding Page vs Document, but it seems
> that other platform-specific clients of this type belong to the Page.
> I agree that it's likely that a platform will use a singleton at the
> lowest level, but the platform can provide the multiplexing whether
> the client is provided to the Page or the Document.
> 
> Steve
> 
> -- 
> Google UK Limited
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
> Registered in England Number: 3977902
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding CSS blending to WebKit

[Dean Jackson]

On 21/07/2012, at 8:50 AM, Rik Cabanier  wrote:

> I'm planning on adding CSS blending to WebKit: 
> https://bugs.webkit.org/show_bug.cgi?id=91908
> We already have a working prototype and I will bring it over as a couple of 
> patches.
> 
> We did a couple of write-ups on this feature:
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
> http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/
> http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/
> http://html.adobe.com/webstandards/csscompositing/
> 
> 
> This is my first time contributing so let me know if there is another process 
> I should follow.

Rik didn't mention this will be protected by a feature flag: 
ENABLE_CSS_COMPOSITING seems to be the suggestion.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS blending to WebKit

[Dean Jackson]

On 28/07/2012, at 11:25 AM, Rik Cabanier  wrote:

> I changed all the project files that were modified for the CSS_SHADERS define 
> but my patch was denied because it didn't modify the makefiles for every 
> single platform.
> Do I really have to modify all of them?

Let's discuss it in the bug so that future webkittens will be able to find it.

https://bugs.webkit.org/show_bug.cgi?id=92553

Dean


> 
> Rik
> 
> On Fri, Jul 27, 2012 at 6:06 PM, Dean Jackson  wrote:
> 
> On 21/07/2012, at 8:50 AM, Rik Cabanier  wrote:
> 
>> I'm planning on adding CSS blending to WebKit: 
>> https://bugs.webkit.org/show_bug.cgi?id=91908
>> We already have a working prototype and I will bring it over as a couple of 
>> patches.
>> 
>> We did a couple of write-ups on this feature:
>> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
>> http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/
>> http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/
>> http://html.adobe.com/webstandards/csscompositing/
>> 
>> 
>> This is my first time contributing so let me know if there is another 
>> process I should follow.
> 
> Rik didn't mention this will be protected by a feature flag: 
> ENABLE_CSS_COMPOSITING seems to be the suggestion.
> 
> Dean
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ANGLE on QNX / non-x11 unixoids

[Dean Jackson]

On Sep 4, 2012, at 10:19 AM, noam.rosent...@nokia.com wrote:

> A
> On Sep 4, 2012, at 8:34 AM, ext Konstantin Tokarev  wrote:
> 
>>> 
>>> To get it compiling, I had to patch ANGLE source code and Simon Hausmann 
>>> told
>>> me he is not comfortable in reviewing these patches. So here I am asking for
>>> how to proceed. Should I first try to upstream these patches to ANGLE 
>>> somehow?
>> 
>> Why do you compe ANGLE? Does QNX support DirectX?
> 
> ANGLE is used to validate and compile WebGL shaders to OpenGL/OpenGL ES2, so 
> it's a dependency regardless of DirectX.

And, as of a recent patch from the Adobe team, it's also used to rewrite the 
content of CSS shaders and add the code which blends the result into the page.

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Experimental features in Safari Web Inspector

[Dean Jackson]

On 26/09/2012, at 6:15 PM, Mihai Balan  wrote:

> We have recently been working on some WebInspector features related to CSS 
> Regions. Most of the work was done using Chromium's Developer Tools, as this 
> allowed us to have this work under a DevTools experiment flag.
> Now that this work has reached a more stable state, it would be useful to 
> test it under Webkit/Safari, too.
>  
> So, my question for you is this (ok, that's actually two questions):
>  
> 1. Is there a way to enable / disable features in Safari DevTools the way 
> it is in Chromium's? It doesn't have to be a GUI, though

No.

> 2. What is the general policy for WebInspector features? How and when do 
> they get enabled by default, at least in the nightlies? (Since regions are 
> already enabled by default in the nightlies, IMO it would make sense to have 
> the web inspector regions features, too)

Safari's Web Inspector lives in the Safari.app, so nightlies do not 
automatically get new features. The best thing to do is implement it in the 
Open Source inspector (as you've done) and Apple will (hopefully) merge it in. 
You can also file a bug at bugreporter.apple.com explicitly requesting it.

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixing requestAnimationFrame

[Dean Jackson]

Me too. Please don't just remove the prefix - we need a period of time where we 
support both prefixed and unprefixed.

Dean

On 12/10/2012, at 6:58 PM, Maciej Stachowiak  wrote:

> 
> I agree with this position as well. It seems good to have a transition period 
> and to gather some data.
> 
>  - Maciej
> 
> On Oct 11, 2012, at 9:59 PM, Darin Fisher  wrote:
> 
>> I agree with what Adam wrote in 
>> https://bugs.webkit.org/show_bug.cgi?id=99116#c5.  Even if a lot of sites 
>> will magically failover to the unprefixed API, we can't know for sure that 
>> this change won't break sites.  We need to give them a chance to update.  (I 
>> don't know if one Chrome release cycle will be enough.)
>> 
>> Why not be conservative here?
>> 
>> -Darin
>> 
>> 
>> On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen  
>> wrote:
>> I've posted a patch to remove the "webkit" prefix from 
>> requestAnimationFrame. [1] The question is whether or not to continue to 
>> support the prefixed version. I propose dropping it for the following 
>> reasons:
>> 
>> 1. We're changing the callback semantics to match the spec. [2]
>> 
>> 2. IE10 is shipping with this unprefixed. [3]
>> 
>> 3. Toolkits already use the unprefixed version. [4]
>> 
>> 4. The advice on the internet recommends everyone use the polyfill 
>> technique. [5]
>> 
>> I'm curious what everyone else thinks.
>> 
>> James
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=99116
>> [2] https://bugs.webkit.org/show_bug.cgi?id=66683
>> [3] http://caniuse.com/#feat=requestanimationframe
>> [4] https://gist.github.com/1579671
>> [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding Web Animations to WebCore

[Dean Jackson]

On Nov 8, 2012, at 4:11 PM, Douglas Stockwell  wrote:

> I wanted to let you know that work has begun on implementing Web Animations 
> in WebKit. New code for this effort will be landed behind the ENABLE_WEB_ANIM 
> feature define and a runtime setting. We expect to be turning this define on 
> for Chromium buildbots so there will be build and test coverage as the new 
> functionality is added.
> 
> The current Editor’s Draft for Web Animations is available at: 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html
> 
> The implementation will be tracked by a meta bug: 
> https://bugs.webkit.org/show_bug.cgi?id=101660

As well as Maciej's concerns, I'd like to add that we already have three 
non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I think 
we need to clean this up before adding any more complexity.

I do very much support the idea of an animation API though.

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit + OpenCL

[Dean Jackson]

On 24/11/2012, at 10:56 AM, Dirk Schulze  wrote:

> 
> On Nov 23, 2012, at 2:43 PM, Andreas Kling  wrote:
> 
>> Hi folks,
>> 
>> Do we really think it's a good idea to add yet another implementation of 
>> filters?
>> 
>> We already have generic, NEON-optimized and WTF::ParallelJobs (which 
>> includes generic, OpenMP and libdispatch backends) implementations of this 
>> code, and now we're adding OpenCL too.
>> 
>> On the WebKit Project Goals page 
>> , it states that:
>> 
>> "WebKit is an engineering project not a science project. For new features to 
>> be adopted into WebKit, we strongly prefer for the technology or at least 
>> the use case for it to be proven."
>> 
>> Correct me if I'm wrong, but we don't see much use of these features on the 
>> web. I understand that there's a bit of a chicken/egg problem where a 
>> feature won't be interesting to content creators until it performs well 
>> enough, but it seems like we could at least decide on a single path forward 
>> instead of repeatedly forking the code.
> 
> I designed the current SVG Filters implementation in a way that hopefully 
> make it possible to implement HW accelerated filters on top of it. Skia and 
> NEON already go this path. I am not defending the OpenCL implementation for 
> SVG Filters per se, but different platform dependent solutions were expected 
> and wanted. Software filters were designed to be a fallback if an 
> implementation does not provide HW acceleration (yet). I hope that we see a 
> Core Image version of filters in the near future as well. The code for that 
> is in the history of the repository already.

FWIW, we currently have an active Core Image filter path on OS X (only for the 
filter shorthands).

Dean

> 
> Greetings,
> Dirk
> 
>> 
>> -Kling
>> 
>> On Nov 21, 2012, at 7:30 PM, Zoltan Herczeg  wrote:
>> 
>>> Hi,
>>> 
>>> we start upstreaming some OpenCL optimizations into WebKit.
>>> 
>>> This is the master bug:
>>> https://bugs.webkit.org/show_bug.cgi?id=70099
>>> 
>>> Regards,
>>> Zoltan
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding Web Animations to WebCore

[Dean Jackson]

Hi Brian,

On 23/11/2012, at 12:01 AM, Brian Birtles  wrote:

>> * At least in its current form, it is overengineered and unusable. An 
>> animation API should focus on ease of use, not combining every conceivable 
>> animation concept ever invented.
> 
> I'd genuinely appreciate your help with regards to identifying specific 
> concerns and unnecessary features. As for usability, I think the video we 
> released shows it's not entirely unusable.[1]
> 
> If the spec seems long it's simply because it's explicitly specifying much of 
> what is left unspecified in SVG and CSS. It's predominantly composed of 
> features already implemented in CSS and SVG. The number of new features is 
> fairly small.
> 
> That said, I think there are some parts of the API we can tighten up and 
> possibly drop. If you have specific suggestions I would really value your 
> comments at public...@w3.org (subject '[web-anim] ... ').

We're planning to send in some comments this week.

> Dean Jackson wrote:
> 
>> As well as Maciej's concerns, I'd like to add that we already have three 
>> non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I 
>> think we need to clean this up before adding any more complexity.
> 
> As I'm sure Dean is well aware, the primary purpose of this specification is 
> to unify the SMIL and CSS models. In Gecko I anticipate replacing much of our 
> SMIL implementation with this API as well as parts of CSS. I see implementing 
> Web Animations as an opportunity to unify this code but you know your 
> codebase best and how best to stage the development.

Yes. My point was that we shouldn't simply "Add Web Animations to WebCore" 
before putting in the required effort on our existing code. We definitely need 
some cleanup, and I'm worried about unifying around an API that isn't stable.

> I agree that there is certainly some tidying up in order. In fact, in my 
> opinion, quite a lot. Development stalled briefly whilst some of us had other 
> duties to attend to but now we're back on deck and looking to get this into 
> FPWD-ready shape by the end of the year so your feedback is very precious. 
> For example, if you have a preference for abbreviated names or not, then by 
> all means please send feedback to public-fx.
> 
>> This doesn't feel baked enough.
> 
> I tend to agree (just look at how many TODOs there still are).
> 
> It's obviously up to you to decide when is the right time to start 
> implementing. In Doug's defence I'd say he is well aware of how much this is 
> still in flux.
> 
> 
> In summary I just want to acknowledge that there is still much work to be 
> done on Web Animations but that it should start moving more quickly in the 
> coming weeks. As a result, your feedback is particularly valuable at this 
> time.
> 
> I also want to apologise if this caught anyone by surprise. We've been 
> posting to public-fx but I realise that not many people monitor that list. 
> I'll try to send a note to www-style in the coming days to alert anyone else 
> who might be interested.

We'll comment on the W3C list rather than here, but in brief (for those who 
don't want to subscribe to another list):

- we'd prefer a much more incremental approach
- we feel this bites off way too much for a V1.0 API (trying to address 
everything at once)
- we'd like to see more declarative support

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixing CSS Animation, Transitions and Transform.

[Dean Jackson]

On 13/12/2012, at 12:49 AM, Alexis Menard  wrote:

> I would like to announce that I will start the work to unprefix CSS
> Animations, Transitions and Transform. It may sounds quick to do but
> it's not, there are few things to do before we can unprefix and
> unleash them to the world (e.g. -webkit-perspective accept valueless
> number but perspective doesn't) and we need to make few fixes to do to
> make sure we are compliant with the spec while keeping the behaviour
> as-is for the current unprefixed version. Also there is few
> unimplemented things.
> 
> The bug is tracked here : https://bugs.webkit.org/show_bug.cgi?id=93136
> 
> In the following days I will add new bugs as blocker to this one to
> track the work left to do. If you think of something missing feel free
> to open a new bug and mark is as blocker for 93136. Please put a
> detailed description on the bug.
> 
> I will land the work behind a feature flag
> CSS_TRANSFORM_ANIMATION_TRANSITION_UNPREFIXED (I accept alternatives
> on the name :), I believe three feature flags for that is overkill)
> enabled by default on trunk as it is important for me to get the bots
> running the code. You can turn off the feature in your release
> branches up until the work is done (maybe afterwards we should even
> remove the feature flag).

Please start with Transitions. They are closer to ready than Animations
and especially Transforms (as you've noted - it needs a lot of work).

Good luck!

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Keeping up with new additions to canvas

[Dean Jackson]

As well as the other suggestions, you can look at bugs in the Canvas component. 
e.g.

https://bugs.webkit.org/show_bug.cgi?id=82790

We should probably have a owner bug to collect all the HTML5-ish Canvas changes.

Dean

On 07/01/2013, at 11:18 PM, RGraph.net support  wrote:

> Hi,
> 
> Is watching this mailing list the best way to keep up-to-date with new
> additions to the WebKit canvas implementation (such as the canvas Path
> object or hit regions)? Or perhaps there's an  announcements list too?
> 
> Thanks!
> 
> -- 
> Richard
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Keeping up with new additions to canvas

[Dean Jackson]

On 09/01/2013, at 9:26 AM, Dirk Schulze  wrote:

> 
> On Jan 8, 2013, at 11:37 AM, Dean Jackson  wrote:
> 
>> As well as the other suggestions, you can look at bugs in the Canvas 
>> component. e.g.
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=82790
> 
> Marked as duplicate ;)

I noticed you forward-duplicated. At Apple we try not to do this, but is
there a convention for WebKit?

Dean

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d

[Dean Jackson]

On 30/01/2013, at 12:46 PM, Dirk Schulze  wrote:

> Would it be possible to clean up the code a bit more and remove the prefixed 
> attributes?

I don't think they should be removed yet. As you mentioned, it's been 16 months 
which is at least one Safari release cycle. I'd prefer that we give a console 
warning for now.

Dean


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

Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.

[Dean Jackson]

Related: when the unprefixed transitions are enabled by default, we plan
to make a long-overdue blog post on "Recent Updates to Transitions and 
Animations"
where "recent" means about 2 or 3 years :)

http://www.webkit.org/blog/?p=2233&preview=true

The idea is that it would cover all the interesting things we've added, even if
we think most people know about them. Feel free to edit the draft (if that's 
possible
- otherwise email me), especially if there are features we've forgotten.

Dean


On 30/01/2013, at 8:03 AM, Alexis Menard  wrote:

> Hi,
> 
> Last month I started working on supporting unprefixed CSS Transitions
> in WebKit. Today this work is guarded behind
> CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in
> trunk (but disabled in Chrome and probably release branches of other
> ports). After various patches we (Dean Jackson and myself) feel
> confident that the work on the transitions is ready for prime time. We
> still have bugs open in our bug tracker but that doesn't block the
> unprefixed version to go live.
> 
> So the proposal is the following one :
> - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to
> CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for
> unprefixing the animations and the transforms (that I plan to focus
> after this).
> - Ship CSS Transitions unprefixed enabled by default with no feature
> flag to disable it.
> 
> My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216
> 
> We can also be proud to say our implementation is maybe the most
> complete one (thanks to the various people involved).
> 
> On a side note the usage of prefixed/unprefixed version is monitored
> through the FeatureObserver so we can later in the future have an idea
> of the usage and maybe remove the prefixed support.
> 
> Thoughts?
> 
> Patched landed :
> http://trac.webkit.org/changeset/141119
> http://trac.webkit.org/changeset/140560
> http://trac.webkit.org/changeset/140448
> http://trac.webkit.org/changeset/140010
> http://trac.webkit.org/changeset/139922
> http://trac.webkit.org/changeset/139762
> http://trac.webkit.org/changeset/139200
> http://trac.webkit.org/changeset/139106
> http://trac.webkit.org/changeset/139070
> http://trac.webkit.org/changeset/138728
> http://trac.webkit.org/changeset/138721
> http://trac.webkit.org/changeset/138184
> 
> Thanks.
> 
> -- 
> Software Engineer @
> Intel Open Source Technology Center
> ___
> 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] Using ninja (was Re:Common build system (was Re: WebKit Wishes))

[Dean Jackson]

OK, this sounds fantastic. And I've noticed how much faster Chromium
incrementally builds using ninja when I've done that.

So, ignoring the discussion of a single build system for a moment, how
can I, as a developer using the OS X + WK2 port, living mostly
in Xcode for editing and debugging, use ninja? I need the idiot's
guide :)

(Note: I am an idiot, but not so much an idiot to realise that the
answer involves lots of work and probably updating some old GYP
files that you and Adam were testing with, etc etc. I'm just selfishly
thinking that cutting even 30s off each incremental rebuild would make
me so much happier that I'd be willing to put up with other
inconveniences.)

Dean

On 03/02/2013, at 4:54 PM, Eric Seidel  wrote:

> +1
> 
> Ninja is beyond-words amazing.  http://martine.github.com/ninja/  For
> better or worse, it is not designed to use human-editable build files,
> but rather to be used by a meta build system, like GYP or CMake.  So
> using ninja is really an orthogonal discussion to the "single build
> system" discussion for WebKit. :)
> 
> Were the WebKit project to convert to using a single meta-build
> system, ninja would become an option many users might choose.  I'm
> told most Chromium hackers have GYP set to output ninja files these
> days, with the exception of some folks who still want the MSVC build
> environment. For WebKit ports already using CMake, they should
> definitely try ninja today!
> 
> 
> Anyway, my wish was not about arguing for a specific build solution.
> I'm instead noting that for the project to continue to move quickly,
> we need to stop needing to edit 8 build systems for every file
> move/addition.  Whether that's GYP or CMake or something else, I don't
> really care.  Adam and I tried GYP-for-WebKIt a while back.  But any
> of these solutions will require buy-in from Apple, as they will have
> to do the largest amount of work converting to use something other
> than XCode.
> 
> 
> On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber  wrote:
>> On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth  wrote:
>>> Ninja has extremely fast incremental builds and can be generated by
>>> GYP.  Here are some stats from a year ago:
>>> 
>>> https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
>>> 
>>> Ninja has gotten even faster since then.  If you're interested in
>>> trying it out, you can play around with incremental builds of the
>>> Chromium port on Mac or Linux.
>> 
>> You can also look at the build output from the chromium bots.
>> 
>> Empty build in 1s:
>> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
>> Build with a few files changed in 15s:
>> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio
>> 
>> …and this is on fairly slow bots. On my SSD-equipped laptop, I can do
>> incremental rebuilds of all of chrome after touching one (cpp or mm)
>> file in 2-6s.
>> 

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

Re: [webkit-dev] sln files with wrong line endings

[Dean Jackson]

On 14/02/2013, at 6:23 pm, Vivek Galatage  wrote:

> I had the same problem and was able to trace the reason for this.
> 
> http://stackoverflow.com/questions/1889559/git-diff-to-ignore-m
> 
> Its the ^M characters at the EOL. git diff --ignore-space-at-eol ignores the 
> change from the diff.
> 
> Something similar was happening with 
> http://trac.webkit.org/browser/trunk/Source/WTF/WTF.vcproj/WTF.sln and its 
> changelog says it.

FWIW, I’ve hit something similar to this when rsyncing repositories between 
machines. All of a sudden, that WTF.sln file is marked as modified, but git 
diff can’t see the change.

I “fix" it by deleting the the .git/index and then doing a git checkout.

Dean

> 
> 
> 
> On Thu, Feb 14, 2013 at 12:40 PM, Christophe Dumez - SISA 
>  wrote:
> Hi,
> 
> The same thing has just happened to me. I managed to get rid of the changes 
> to this file by doing:
> git reset --hard
> 
> Kr,
> Christope Dumez.
> 
> From: webkit-dev-boun...@lists.webkit.org 
> [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel 
> [e...@webkit.org]
> Sent: Thursday, February 14, 2013 08:23
> To: WebKit Development
> Subject: [webkit-dev] sln files with wrong line endings
> 
> We've had this come up before, but I figure I should ask on webkit-dev
> to see if we have a solution. :)
> 
> Right now the Tools/DumpRenderTree/DumpRenderTree.vcxproj/DumpRenderTree.sln
> file is in some sort of bad state such that my Git checkout can't seem
> to not-modify the file.
> 
> I'm not sure if it's a Git bug, or a repository config bug.
> 
> But it means I can't seem to produce patches w/o modifying this file. :(
> 
> https://bugs.webkit.org/attachment.cgi?id=188263&action=review
> 
> Thoughts?
> ___
> 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

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

Re: [webkit-dev] CSS filter behavior change - what is our policy?

[Dean Jackson]

On 15/03/2013, at 4:45 AM, Noam Rosenthal  wrote:

> How do we go about rendering behavior changes that affect features that are 
> enabled on shipping browsers?
> 
> I'm specifically referring to http://trac.webkit.org/changeset/139770 
> The brightness filter is enabled by default on chrome and Safari if I 
> remember correctly, and now pages that use brightness(0) would have their 
> element blackened, while before those elements would have been left 
> unchanged. This is of course "correct" so I can't claim it's a bug, but still 
> it would break existing websites, even if not many.
> 
> Do we see CSS filters as being "bleeding edge" enough where we don't care? Do 
> we have a way to warn web developers about this? They'd basically have to 
> check Chrome/Safari/Other version in order to work around the problem, as 
> there's no media query for "check if brightness behaves correctly".

I think in this case it was enough of a combination of "bleeding edge" + 
definite bug (where bleeding edge is determined by it being a prefixed property 
that isn't even at the candidate recommendation stage as well has young enough 
to not have widespread use). But you raise a good point - I would have been 
more reluctant to make this change as time passed.

Dean

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

Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

I'm not sure I like this proposal. Why is canvas special? Why doesn't  get 
an opaque attribute (or flag)? Why not every element?

I don't think the performance benefit, which is mostly going to be on very 
limited hardware, is worth changing the rendering model that is consistent 
across every other part of the Web.

Dean

On 15/03/2013, at 4:53 AM, Stephen White  wrote:

> Hi Dirk,
> 
> There have been at least five options considered, with contributions from 
> Chromium, Adobe and Mozilla so far.  The moz-opaque idea was first floated by 
> Robert O'Callahan from Mozilla, and Ian Hickson offered to spec it if another 
> browser vendor wanted to implement it.  I took him up on that offer, and have 
> made my humble effort to massage it into a concrete proposal in the linked 
> message above.
> 
> After proposing it here, the alternative suggestion is to sync it up with the 
> WebGL syntax, and use a context creation object at getContext() time rather 
> than an attribute on the  element.  I have no strong feelings about 
> this either way, and I'm working on a patch to try out the WebGL approach (I 
> already have a WebKit patch which implements the platform-independent parts 
> of the opaque attribute approach).  However, if we do go that way, I'd prefer 
> not to make this proposal conditional on changes to the WebGL spec, concerns 
> which I've outlined over on what-wg.
> 
> Stephen
> 
> 
> On Wed, Mar 13, 2013 at 12:30 PM, Dirk Schulze  wrote:
> This is a very long thread and I did not see any conclusions or agreement on 
> this thread. Can you summarize the topic and the status on the acceptance 
> level please?
> 
> Greetings,
> Dirk
> 
> On Mar 13, 2013, at 9:15 AM, Stephen White  wrote:
> 
> > Hi WebKittens,
> >
> > I'm planning to implement the canvas "opaque" attribute, as proposed here:  
> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html.
> >
> > This is an attribute that causes the allocation of an opaque backing store 
> > for , allowing optimizations at the time the canvas is composited 
> > into the page, such as disabling blending and culling obscured content.  It 
> > is based on the moz-opaque attribute currently shipping in Firefox.
> >
> > I'll be placing the feature behind the build-time flag 
> > ENABLE(OPAQUE_CANVAS).
> >
> > Let me know if you have any comments or concerns.
> >
> > Stephen
> > ___
> > 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] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 6:50 AM, Dana Jansens  wrote:

> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson  wrote:
> I'm not sure I like this proposal. Why is canvas special? Why doesn't  
> get an opaque attribute (or flag)? Why not every element?
> 
> There is ongoing work to infer opaqueness in every other kind of element when 
> possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634

Yes, I'd prefer to infer it rather than specify it. For example, I could infer 
that a canvas is opaque if it has a non-transparent CSS background-color.

Dean

>  
> 
> I don't think the performance benefit, which is mostly going to be on very 
> limited hardware, is worth changing the rendering model that is consistent 
> across every other part of the Web.
> 
> Dean
> 
> On 15/03/2013, at 4:53 AM, Stephen White  wrote:
> 
>> Hi Dirk,
>> 
>> There have been at least five options considered, with contributions from 
>> Chromium, Adobe and Mozilla so far.  The moz-opaque idea was first floated 
>> by Robert O'Callahan from Mozilla, and Ian Hickson offered to spec it if 
>> another browser vendor wanted to implement it.  I took him up on that offer, 
>> and have made my humble effort to massage it into a concrete proposal in the 
>> linked message above.
>> 
>> After proposing it here, the alternative suggestion is to sync it up with 
>> the WebGL syntax, and use a context creation object at getContext() time 
>> rather than an attribute on the  element.  I have no strong feelings 
>> about this either way, and I'm working on a patch to try out the WebGL 
>> approach (I already have a WebKit patch which implements the 
>> platform-independent parts of the opaque attribute approach).  However, if 
>> we do go that way, I'd prefer not to make this proposal conditional on 
>> changes to the WebGL spec, concerns which I've outlined over on what-wg.
>> 
>> Stephen
>> 
>> 
>> On Wed, Mar 13, 2013 at 12:30 PM, Dirk Schulze  wrote:
>> This is a very long thread and I did not see any conclusions or agreement on 
>> this thread. Can you summarize the topic and the status on the acceptance 
>> level please?
>> 
>> Greetings,
>> Dirk
>> 
>> On Mar 13, 2013, at 9:15 AM, Stephen White  wrote:
>> 
>> > Hi WebKittens,
>> >
>> > I'm planning to implement the canvas "opaque" attribute, as proposed here: 
>> >  
>> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html.
>> >
>> > This is an attribute that causes the allocation of an opaque backing store 
>> > for , allowing optimizations at the time the canvas is composited 
>> > into the page, such as disabling blending and culling obscured content.  
>> > It is based on the moz-opaque attribute currently shipping in Firefox.
>> >
>> > I'll be placing the feature behind the build-time flag 
>> > ENABLE(OPAQUE_CANVAS).
>> >
>> > Let me know if you have any comments or concerns.
>> >
>> > Stephen
>> > ___
>> > 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
> 
> 

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

Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 7:45 AM, Kenneth Russell  wrote:

> On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa  wrote:
>> On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson  wrote:
>>> 
>>> 
>>> On 15/03/2013, at 6:50 AM, Dana Jansens  wrote:
>>> 
>>> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson  wrote:
>>>> 
>>>> I'm not sure I like this proposal. Why is canvas special? Why doesn't
>>>>  get an opaque attribute (or flag)? Why not every element?
>>> 
>>> 
>>> There is ongoing work to infer opaqueness in every other kind of element
>>> when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634
>>> 
>>> 
>>> Yes, I'd prefer to infer it rather than specify it. For example, I could
>>> infer that a canvas is opaque if it has a non-transparent CSS
>>> background-color.
>> 
>> 
>> I like this approach. It means that developers don't have to explicitly use
>> this feature to get the performance benefits.
>> 
>> In fact, this is the preferred performance optimization approach on the Web.
>> We don't provide explicit APIs to optimize performance. We make sensible
>> APIs which allows us to implement more optimizations on common cases behind
>> the scene.
> 
> Not to put words in Stephen's mouth, but as I understand it, the main
> reason for adding this attribute is to enable higher-quality,
> LCD-antialiased text on canvases.
> 
> Without it, it's impossible (or, at least, very difficult and low
> performance) to infer whether it's legal to use LCD antialiasing. Most
> ports' Canvas 2D implementations are GPU-accelerated, and it would be
> necessary to test all pixels underneath the text to ensure they are
> fully opaque before drawing the text. This would require a readback of
> the canvas's contents from the GPU, which would perform very poorly.

Yes, we get complaints about this all the time. But it seems to reenforce
my point that canvas is not special here. I expect more text to be 
rendered in non-canvas elements than canvas, and those elements could
be GPU-accelerated as well (they often are on Apple platforms).

However, your point does mean that simply testing the CSS background-color
will not work in all cases. For example, drawing a canvas into another
canvas. But in that case, unless you're drawing 1:1 and on a pixel boundary,
your subpixel antialiasing is going to be screwy anyway.

Dean

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

Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 7:55 AM, Gregg Tavares  wrote:

> 
> 
> 
> On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa  wrote:
> On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson  wrote:
> 
> On 15/03/2013, at 6:50 AM, Dana Jansens  wrote:
> 
>> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson  wrote:
>> I'm not sure I like this proposal. Why is canvas special? Why doesn't  
>> get an opaque attribute (or flag)? Why not every element?
>> 
>> There is ongoing work to infer opaqueness in every other kind of element 
>> when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634
> 
> Yes, I'd prefer to infer it rather than specify it. For example, I could 
> infer that a canvas is opaque if it has a non-transparent CSS 
> background-color.
> 
> The content of the canvas has to be blended with the background color so that 
> doesn't help optimization. If there's a background color you first have to do 
> a full blend of the contents of the canvas with the background color. Where 
> as if the canvas has no alpha then that step can be avoided.

We're probably getting a bit off the general topic here, but why don't you 
consider the background color as a fillRect(0, 0, width, height) on the empty 
canvas? As has been said, this doesn't change the behaviour of the 
painting/blending operations in the canvas itself, just how it is composited 
into the document.

I guess we should take this conversation to the HTML list.

Dean

> 
>  
> 
> I like this approach. It means that developers don't have to explicitly use 
> this feature to get the performance benefits.
> 
> In fact, this is the preferred performance optimization approach on the Web. 
> We don't provide explicit APIs to optimize performance. We make sensible APIs 
> which allows us to implement more optimizations on common cases behind the 
> scene.
> 
> - R. Niwa
> 
> 
> ___
> 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] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 8:06 AM, Gregg Tavares  wrote:

> Because it's not the same as fillRect(0, 0, width, height) on an empty 
> canvas. The canvas itself has alpha (unless we add the option to not have it 
> as has been proposed). The contents of the canvas has to stay as the user 
> created it. If I draw with rgba(255,255,0, 0.5) I expect if I read data out 
> of the canvas or draw that canvas into another canvas I'll get that color, 
> not the color blended with the css background.

Yes, this is what I said in another email. Maybe I'm misunderstanding this, but 
if the main concern is to guarantee nice subpixel-antialiased text in canvas 
(but not anywhere else, such as the 99.99% of places where people draw text) 
then well, I'm still not convinced opaque is a great idea :) Especially not 
as an HTML attribute.

There are obviously ways to get around the problems you mentioned above (e.g. 
two buffers + two draws, or keeping a display list until someone wants to read 
out, etc) and, even more obviously, they have significant problems. It just 
seems to me that we're trying to address the issue of wanting nice looking text 
with a very specific solution on one element. Maybe we should consider what we 
could do across the platform?

Dean


> So, the canvas has to be blended if there's alpha. There's no magic getting 
> around that. The only way around it is to give the user a way to say "no 
> alpha".



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

Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 12:49 PM, Vladimir Vukicevic  wrote:

> On 3/14/2013 5:23 PM, Dean Jackson wrote:
>> On 15/03/2013, at 8:06 AM, Gregg Tavares  wrote:
>>> Because it's not the same as fillRect(0, 0, width, height) on an empty 
>>> canvas. The canvas itself has alpha (unless we add the option to not have 
>>> it as has been proposed). The contents of the canvas has to stay as the 
>>> user created it. If I draw with rgba(255,255,0, 0.5) I expect if I read 
>>> data out of the canvas or draw that canvas into another canvas I'll get 
>>> that color, not the color blended with the css background.
>> Yes, this is what I said in another email. Maybe I'm misunderstanding this, 
>> but if the main concern is to guarantee nice subpixel-antialiased text in 
>> canvas (but not anywhere else, such as the 99.99% of places where people 
>> draw text) then well, I'm still not convinced opaque is a great idea :) 
>> Especially not as an HTML attribute.
> 
> The main concern for us was performance -- if you have a large canvas, 
> whether on mobile or on desktop, it is beneficial to tell the browser that it 
> is guaranteed opaque, and it can allocate backing store and draw it as such.  
> There's no way to infer that... checking the CSS background doesn't work for 
> the reasons Gregg outlined.  Basing it on a fillRect() of the entire canvas 
> with a non-opaque color doesn't work, because there are blend modes that will 
> punch holes in alpha.  So you can have a really complicated heuristic to try 
> to get it right and miss in a bunch of cases, or you can just "make it work" 
> in the general case (have alpha), and let developers who are trying to 
> squeeze the last bit of performance out of the platform give you the hints 
> you need.  We opted for the latter approach.

Fair enough. I'm not arguing against the benefits - as I said, we get the 
request all the time. I'm just hoping there is a way we can do this for more 
elements than just canvas. 

If we do decide this is canvas only, I don't like an attribute on the element. 
That seems too presentational. It's the script that decides what is drawn into 
canvas, so the script should probably decide whether or not to tell the 
implementation it might be able to optimise by not allocating an alpha channel. 
So count me in the camp that agrees with context attributes.

Just calling it "alpha" is also a bit confusing, because alpha will still work 
within the canvas itself.

Dean

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

[webkit-dev] Alexandru Chiculita is now a WebKit reviewer

[Dean Jackson]

I'm happy to announce that Alex is now a WebKit reviewer. Congratulations Alex!

Alex has done a lot of work in CSS Filters, amongst other places. For those who 
want to see him in action, here is his recent presentation at W3Conf:

   http://achicu.github.com/css-presentation/
   http://www.youtube.com/embed/D7gsp7RnDfc

Dean

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

[webkit-dev] Enabling new features in WebKit + prefixing

[Dean Jackson]

This is a brief summary of yesterday's discussion at the contributors' meeting. 
If there is no strong disagreement here then I'll add this to the wiki.

New Features


- The rule of sending an email to webkit-dev when you're about to start work on 
a new feature remains in place. The idea here is that the community can support 
or object to the feature even being in the tree.

- Once the implementation of the feature is ready for use, send another email 
to webkit-dev announcing your intentions to enable the feature in nightly 
builds. How do you know when something is "ready for use"?

  + You want external developers to play with it and provide feedback (either 
to WebKit or a standards body)
  + Bugs and (some) crashes are ok, although it would be great if they were 
minimised.
  + Security and privacy issues are **NOT** ok. e.g. if the specification 
describes a security issue with no known solution, or if the known solution has 
not yet been implemented, then the feature should not be enabled.

If there is general agreement on the list then go ahead and enable the feature 
for nightlies. Port owners now have the responsibility to disable it for their 
shipping branches.

- If you're in a middle ground then you may consider enabling the feature for 
compilation, but protecting it behind a runtime flag that is disabled by 
default. Again, you should send an email to webkit-dev announcing this. An 
example of this would be a feature where security issues have been suggested 
but not confirmed.


Prefixing
-

- We still recommend prefixing on most new features while they are unstable. 
e.g. CSS properties and property values, if necessary. This is different from 
the Blink and Mozilla approach (which is to not prefix).

- We will now avoid prefixing on our file names. e.g. WebKitCSSMatrix should be 
just CSSMatrix. This might need some changes in the binding generators.

- If possible, prefer no prefixing in IDL and event names. Of course, for a 
truly new Web-exposed feature, this might be impossible.


Unprefixing
---

- We want to unprefix things as soon as we can. This relates back to the 
stability point above, which is hard to determine. Blink are trying to track 
stability here -> [1].

- We think there are many things in WebKit that can now be unprefixed. Alexis 
did a great job unprefixing CSS transitions - follow his lead.

- We will continue to support the prefixed properties for some amount of time, 
decided on a case-by-case basis.

[1] http://www.chromestatus.com/features



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

Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies

[Dean Jackson]

On May 9, 2013, at 6:13 PM, Mark Rowe  wrote:

> The only platform for which nightly builds are produced is OS X. Do you 
> intend to enable it for all platforms on tip of tree, or just for those from 
> which nightly builds are built?
> 
> What I'm getting at is that I'm confused as to why you mentioned nightly 
> builds at all in your initial email if you're enabling it for all platforms.

We had a discussion about this at the contributor's meeting. I sent a draft 
resolution, which Bear linked to.

The idea is that people would send an email to the list when a feature is about 
to be enabled by default (at compile time, and at run time if they have such a 
flag, although we're trying to avoid that). It then is testable in Nightly 
builds.

So the goal is to allow people to use and test the feature. The fact that OS X 
is the only platform producing Nightly builds makes this a little weird, 
because it means you really only have to enable for OS X, but let's assume more 
platforms join the nightly party at some point.

Dean

> 
> - Mark
> 
> On May 9, 2013, at 17:49, Bear Travis  wrote:
> 
>> Hi Mark,
>> 
>> Yes, my understanding of the policy [1] was that this was done at tip of 
>> tree.
>> 
>> -Bear
>> 
>> [1] https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html
>> 
>> From: Mark Rowe 
>> Date: Thursday, May 9, 2013 5:25 PM
>> To: Adobe 
>> Cc: "webkit-dev@lists.webkit.org" 
>> Subject: Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies
>> 
>> 
>> On 2013-05-09, at 17:21, Bear Travis  wrote:
>> 
>>> Hi WebKit,
>>> 
>>> The CSS Exclusions & Shapes [1] feature is currently behind a runtime flag 
>>> that I would like to enable by default in the WebKit nightlies.
>> 
>> Can you clarify what it means to enable something by default in "the WebKit 
>> nightlies”? Do you mean enabling it by default on tip of tree?
>> 
>> - Mark
>> 
>> 
> ___
> 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] Fuzzinator, a mutation based web fuzzer

[Dean Jackson]

On 27/06/2013, at 2:48 AM, Renáta Hodován  wrote:

> On 06/26/2013 12:30 AM, Zoltan Horvath wrote:
>> Hey Reni,
>> 
>> This project sounds cool! I think you will answer some of my questions in 
>> your blog post, so I don't ask just one now...
>> 
>> Do you know the date it's going to be published?
>> 
> Hopefully next week you can read it ;)

Is it out yet?

Dean

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

Re: [webkit-dev] XML Serialization Issues

[Dean Jackson]

I believe the tests you added are not reliable across runs. In particular, the 
unique id you generate
isn’t necessarily always the same, but your -expected.txt is just a dump of the 
DOM.

I filed: http://webkit.org/b/120490, but I only mentioned one test. Since then 
I’ve seen more fail.

Dean

On 30 Aug 2013, at 3:25 am, Rob Buis  wrote:

> Fixed.
> 
> More seriously, all bugs mentioned below are fixed/closed, please open
> new ones for any regressions/improvements.
> Cheers,
> 
> Rob.
> 
> On 19 June 2013 14:44, Alex Milowski  wrote:
>> I was working on using MathJax [1] to turn MathML into SVG and ran into some
>> serious serialization issues.  In summary, as MathJax programmatically
>> creates SVG renderings of the MathML, when it creates XLink attributes, it
>> doesn't seem to define a prefix.  While this works for rendering, it does
>> when you try to extract a serialization of the SVG.
>> 
>> That is, MathJax creates SVG 'use' elements like (assuming SVG as the
>> default namespace):
>> 
>> http://www.w3.org/1999/xlink"/>
>> 
>> but instead I get:
>> 
>> http://www.w3.org/1999/xlink"/>
>> 
>> which makes the SVG incorrect as the 'use' element is now in the xlink
>> namespace.
>> 
>> You can work around this by manually setting the "prefix" property on each
>> xlink:href attribute.
>> 
>> Looking into why this happens, I can see that the serializer seriously
>> broken in a number of ways when the DOM is constructed with incomplete (e.g.
>> missing namespace declarations) or inconsistent information (e.g. same
>> prefix used for different namespaces in the same context).
>> 
>> I found at least 6 bugs outstanding (#16739 [2], #16496 [3], #19121 [4],
>> #22958 [5], #83056 [6], #106531 [7]) and filed a new one (#117764 [8]).
>> Some of these date back to 2007 (6 years ago!).
>> 
>> These bugs break down to these categories:
>> 
>> 1. Default namespace issues: #16739, #106531, #16496
>> 2. Conflicting prefix mappings: #117764, #19121
>> 3. Namespace attribute issues: #22958, #83056, #117764
>> 
>> In looking at the code (MarkupAccumulator.cpp), they all suffer from one of
>> two problems:
>> 
>> 1. The computed prefix used isn't properly used for the declaration.
>> 
>> 2. The generated namespace mappings aren't properly stored, scoped, or dealt
>> with when they are inconsistent.
>> 
>> There is an general assumption in the code that certain prefixes should
>> always be used for certain namespaces.  Unfortunately, it does so without
>> looking to see whether there is a conflict already in scope.  Also, when the
>> namespace is not recognized and there is no prefix, a prefix needs to be
>> generated for the serialization.
>> 
>> Having written several robust XML Serializers for other projects, this can
>> all be fixed in a straightforward way.  I've looked at the code and know
>> what should be done.  The changes are probably modest.
>> 
>> Unfortunately, I can't spend the time to directly write and test the code
>> till probably after November.  :(
>> 
>> I am certainly willing to help, explain my strategy, advise, test, etc. if
>> there was another willing developer out there who would like to see these
>> bugs closed.
>> 
>> [1] http://www.mathjax.org/
>> [2] https://bugs.webkit.org/show_bug.cgi?id=16739
>> [3] https://bugs.webkit.org/show_bug.cgi?id=16496
>> [4] https://bugs.webkit.org/show_bug.cgi?id=19121
>> [5] https://bugs.webkit.org/show_bug.cgi?id=22958
>> [6] https://bugs.webkit.org/show_bug.cgi?id=83056
>> [7] https://bugs.webkit.org/show_bug.cgi?id=106531
>> [8] https://bugs.webkit.org/show_bug.cgi?id=117764
>> 
>> 
>> --
>> --Alex Milowski
>> "The excellence of grammar as a guide is proportional to the paucity of the
>> inflexions, i.e. to the degree of analysis effected by the language
>> considered."
>> 
>> Bertrand Russell in a footnote of Principles of Mathematics
>> 
>> ___
>> 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] Announcement: CSS3_TEXT_DECORATION flag

[Dean Jackson]

Yeah, as we agreed at the contributor’s meeting, if we think a feature is ready 
for experimentation, and we think it will eventually be enabled (e.g. there is 
a stable-ish spec), then we turn it on for nightly builds.

I assume that this doesn’t break any existing decoration code?

Dean

On 5 Oct 2013, at 4:24 am, Sam Weinig  wrote:

> Or better yet, enable it for all ports on ToT.
> 
> -Sam
> 
> On Oct 4, 2013, at 11:03 AM, Timothy Hatcher  wrote:
> 
>> Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?
>> 
>> I have a legitimate use for -webkit-text-decoration-color that would allow 
>> me to eliminate a hack in the Inspector.
>> 
>> — Timothy Hatcher
>> 
>> 
>> On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield  wrote:
>> 
>>> Hello, all!
>>> 
>>> Between the current and previous versions of the CSS3 Text spec, the text 
>>> decoration section was split out into its own spec [1] [2] [3]. Because of 
>>> this shift, I’m going to be creating a new compile-time flag: 
>>> CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned 
>>> in [4]. For those who wish to follow progress, the feature bug is at [5]. 
>>> The first thing I am working on is the text-decoration-skip: ink property 
>>> [6]. I will also be migrating existing text-decorations code from behind 
>>> the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
>>> 
>>> Thanks,
>>> Myles C. Maxfield
>>> 
>>> [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
>>> [2] http://www.w3.org/TR/css3-text/
>>> [3] http://www.w3.org/TR/css-text-decor-3/
>>> [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
>>> [5] https://bugs.webkit.org/show_bug.cgi?id=58491
>>> [6] https://bugs.webkit.org/show_bug.cgi?id=121806
>>> ___
>>> 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

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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 3 Oct 2013, at 4:46 am, Christian Biesinger  wrote:

> On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa  wrote:
>> On Tue, Oct 1, 2013 at 4:53 PM, James Craig  wrote:
>>> 
>>> Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
>>> should we temporarily use “-webkit-alt” for the property name? I know there
>>> has been a push to move away from vendor prefixes lately, so if there are no
>>> objections, I propose we use the unprefixed version.
>> 
>> 
>> I think that's what Mozilla and Google are doing but I don't think we
>> necessary have to follow the suit.
> 
> FYI, because IMO this is an important clarification - Mozilla and
> Google use unprefixed versions only *behind a (runtime) flag*, until
> the spec is stable. That way experimental features are not exposed to
> the web at large until it is unlikely that the spec will change, to
> avoid cross-browser compatibility risks.

We decided on a slightly different approach, which is to prefix things
but enable them by default in nightly builds. That way a port must still
decide at their shipping time whether or not to enable the feature.

In the Moz + Google case, the experimental form is exposed unprefixed to a small
number of users on the Web. In our case, the experimental form is exposed
prefixed. We concluded that we’ve changed things enough times while prefixed
that it was worth the extra “this is experimental and may change” notice.

Dean


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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 5 Oct 2013, at 6:22 am, Adam Barth  wrote:

> On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson  wrote:
>> On 3 Oct 2013, at 4:46 am, Christian Biesinger  
>> wrote:
>>> On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa  wrote:
>>>> On Tue, Oct 1, 2013 at 4:53 PM, James Craig  wrote:
>>>>> 
>>>>> Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
>>>>> should we temporarily use “-webkit-alt” for the property name? I know 
>>>>> there
>>>>> has been a push to move away from vendor prefixes lately, so if there are 
>>>>> no
>>>>> objections, I propose we use the unprefixed version.
>>>> 
>>>> I think that's what Mozilla and Google are doing but I don't think we
>>>> necessary have to follow the suit.
>>> 
>>> FYI, because IMO this is an important clarification - Mozilla and
>>> Google use unprefixed versions only *behind a (runtime) flag*, until
>>> the spec is stable. That way experimental features are not exposed to
>>> the web at large until it is unlikely that the spec will change, to
>>> avoid cross-browser compatibility risks.
>> 
>> We decided on a slightly different approach, which is to prefix things
>> but enable them by default in nightly builds. That way a port must still
>> decide at their shipping time whether or not to enable the feature.
>> 
>> In the Moz + Google case, the experimental form is exposed unprefixed to a 
>> small
>> number of users on the Web. In our case, the experimental form is exposed
>> prefixed. We concluded that we’ve changed things enough times while prefixed
>> that it was worth the extra “this is experimental and may change” notice.
> 
> Does this imply that you'll remove the prefixes before shipping the
> features in a production release?

I can’t speak for anyone other than the Apple port, and even there I’m
definitely not the official word on the topic, but I don’t think that is
implied. It’s likely going to depend on perceived stability of the feature,
testing, community feedback, etc.

The important thing is that our goal is to get to the unprefixed stable form
as soon as possible.

Also, our prefixing/unprefixing rules are not set in stone. I think the 
community
will evaluate them case by case.

Dean


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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dean Jackson]

On 5 Oct 2013, at 6:45 am, Adam Barth  wrote:

>> Also, our prefixing/unprefixing rules are not set in stone. I think the 
>> community
>> will evaluate them case by case.
> 
> I would encourage you (and others) not to ship new vendor-prefixed
> APIs in production releases.  If the feature isn't stable enough to
> ship without a prefix, it's also harmful to the web ecosystem to ship
> with a vendor prefix.

We’re well aware of the risks and benefits. This ain’t our first
time at the rodeo.

Dean

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

[webkit-dev] Animations feature flag

[Dean Jackson]

Hi floks,

I’m about to add a flag WEB_ANIMATIONS, behind which I’ll start:

- Implementing an animation engine that matches the model in W3C’s Web 
Animation spec
- Allowing CSS and SVG animations to use the new engine
- Exposing enough internal JS API to allow improved testing (currently a very 
weak point for us)
- Possibly looking at implementing parts of the public API

The last point was controversial when it was raised here a while ago. We should
discuss it again when we have something to implement upon.

There will also be a runtime flag to enable the new engine. With the flag 
disabled,
nothing should break. Eventually we’ll be able to toggle the flag and have a 
better
animation engine.

Dean

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

[webkit-dev] Mihnea-Vlad Ovidenie is now a reviewer

[Dean Jackson]

My Fellow Community,

I’m happy to announce that Mihnea is a WebKit reviewer. As you might now, 
Mihnea has done a lot of work in layout, particularly CSS Regions and 
Exc^H^H^HShapes.

Please send him all your patches!! :)

Dean

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

Re: [webkit-dev] Animations feature flag

[Dean Jackson]

On 17 Oct 2013, at 2:22 am, Dirk Schulze  wrote:

> Did you already open a master bug for the upcoming changes? Can you add a 
> link please?

Good point! http://webkit.org/b/122912

Dean

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

Re: [webkit-dev] Animations feature flag

[Dean Jackson]

On 17 Oct 2013, at 6:35 am, Dean Jackson  wrote:

> 
> On 17 Oct 2013, at 2:22 am, Dirk Schulze  wrote:
> 
>> Did you already open a master bug for the upcoming changes? Can you add a 
>> link please?
> 
> Good point! http://webkit.org/b/122912

I forgot to add that there is now a bugzilla component for Animations. This 
should
hold all the new things, as well as bugs in CSS transitions and animations (and
SVG animations I guess).

Dean

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

Re: [webkit-dev] The SrcN responsive images proposal

[Dean Jackson]

On 5 Nov 2013, at 9:55 am, Timothy Hatcher  wrote:

> On Nov 5, 2013, at 2:18 AM, John Mellor  wrote:
> 
>> 
> 
> I prefer this over multiple attributes. It is a syntax that needs little 
> explanation before you can read it and use it. It also expands the existing 
> srcset instead of confusing things with other attributes.
> 
> srcN is also too fiddly. If you want to add a higher precedent srcN, you need 
> to reorder all the existing srcN attribute names. With srcset you just need 
> to edit a single attribute's value, adding a logic operator between the rules.

This is a great point.

Also, we should be mindful that whatever solution should be vaguely applicable 
to other contexts where you’re selecting resources based on resolution, etc, 
such as video and CSS properties. I don’t want an explosion of attributes 
everywhere, and I don’t even know how you’d do that in CSS (background-image-1, 
background-image-2, …)

Dean

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

Re: [webkit-dev] The SrcN responsive images proposal

[Dean Jackson]

[And the holy book sayeth cursed is she who participates in standards email, 
doomed forever to receive email in CC and being unable to sleep at night. ]

On 7 Nov 2013, at 17:43, "Tab Atkins Jr."  wrote:

>> A proposal for a new paradigm of using multiple attributes deserves some 
>> resistance, careful consideration and exploration of alternatives. I feel my 
>> factual example of  was flippantly tossed aside. So I responded in 
>> jest.
> 
> Apologies if you believed my response was flippant; it was short, but
> serious and to the point.  I explained why the  example wasn't
> very good - it's a single (albeit way overcomplicated) list of
> commands.  The src-N attributes already contain lists, so they're
> comparable.  I'm objecting to combining the src-N attributes into a
> single attribute because that produces a *list of lists*, which is a
> significant step further in mental complexity.

one of the things I liked about srcset is that in the most urgent case it is 
simply one extra attribute with one higher resolution image. 

once we get into structure and ordering and multiple options and art direction 
any of these attribute solutions looks horrible. I don't care whether it is one 
attribute or 99, it's a pain to understand. if you want structure, use markup. 
I'm tempted to think the  element is a better solution for these 
advanced cases. 

fwiw path d is an attribute because we expected thousands of values in that and 
structure would have been too unwieldy. 

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

[webkit-dev] Nesting a new CSS_SHAPES flag

[Dean Jackson]

Hi Floks!

We currently have flags for both CSS_SHAPES and CSS_EXCLUSIONS. In the former, 
shape-outside is nearly complete (thanks to hard work from Adobe contributors 
and others), but shape-inside is still waiting on a layout implementation, and 
is dependent on future specification work in CSS Exclusions.

In order to make it easy for ports to ship the bits that are stable 
(shape-outside) while disabling the bits that are not (shape-inside), I'm going 
to add a CSS_SHAPE_INSIDE flag. It will be dependent on CSS_SHAPES.

Dean


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

[webkit-dev] WebGL backends

[Dean Jackson]

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

Re: [webkit-dev] WebGL backends

[Dean Jackson]

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Dean Jackson]

On 14 Feb 2014, at 12:17 am, Sergio Villar Senin  wrote:

> En 11/02/14 21:04, Maciej Stachowiak escribiu:
 
 Why not enabling the feature entirely on trunk? (and disable it when
 shipping product by disabling the compile time flag?).
 I think feature doing that tends to become stable a lot quicker.
>> Occasionally a feature is so experimental you don't even want it in nightly 
>> builds - it would cause too much instability.
>> 
>> But it's true, a lot of the time a feature is ready for testing in nightlies 
>> or developer builds, but should not be shipped just yet. I think a runtime 
>> flag is actually a good way to do that. The code that will actually compile 
>> and ship can more easily be tested that way (by testing with both modes of 
>> the flag).
> 
> So if I understood correctly the idea would be to bring the feature flag
> back and at the same time switch the runtime flag on by default for all
> the ports right?

FWIW this is what we agreed to do at the contributor’s meeting last year.

Enable by default in ToT (and thus nightly builds).
Compile-time disable on a shipping branch if you don’t want to expose it.

It’s not a hard rule though.

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

Re: [webkit-dev] WebGlRendering Context Restored and Lost

[Dean Jackson]

Hi Rakesh,

On 21 Feb 2014, at 2:18 pm, Rakesh Sadhu  wrote:

> I have a question, When a glcontext is lost and again restored , what should 
> be the behaviour of associated extensions ?

When a ContextLost occurs on a WebGLRenderingContext all extensions should be 
reset, as described by the specification (with the exception of the special 
extension that can manually trigger a ContextLost). This doesn’t necessarily 
mean the values get NULLed (since you may have an existing reference), just 
that they will fire exceptions if you use them.

I have an in-progress pull request on a test case for this, on the Khronos 
github repository.

BTW - this question is probably best suited to the WebGL mailing lists, unless 
you think there is a WebKit bug.

Dean

> I have a test case  
> http://www.khronos.org/registry/webgl/sdk/tests/conformance/context/context-lost-restored.html,
> and in it I am confused to see  that upon context restoration , test case 
> expects extension 's related API's to be NULL .
> 
> here is the  js code snippet from above mentioned link:
> 
> 
> function testOESVertexArrayObject() {
>   if (OES_vertex_array_object) {
> // Extension must still be lost.
> shouldBeNull("OES_vertex_array_object.createVertexArrayOES()");  // WHY 
> 
> // Try re-enabling extension
> 
> old_OES_vertex_array_object = OES_vertex_array_object;
> OES_vertex_array_object = reGetExtensionAndTestForProperty(gl, 
> "OES_vertex_array_object", false);
> shouldBeTrue("OES_vertex_array_object.createVertexArrayOES() != null");
> shouldBeTrue("old_OES_vertex_array_object.createVertexArrayOES() == 
> null");
>   }
> }
> 
> function testExtensions() {
>   testOESTextureFloat();
>   testOESVertexArrayObject();
>   // Only the WEBGL_lose_context extension should be the same object after 
> context lost.
>   new_WEBGL_lose_context = reGetExtensionAndTestForProperty(gl, 
> "WEBGL_lose_context", true);
> }
> 
> 
> ///  this function is a callback function , which is attached to 
> addeventlistener in above mention link//
> 
> function testRestoredContext()
> {
> debug("Test restored context");
> shouldBeFalse("contextRestoredEventFired");
> contextRestoredEventFired = true;
> shouldBeFalse("gl.isContextLost()");
> shouldBe("gl.getError()", "gl.NO_ERROR");
> 
> // Validate that using old resources fails.
> testResources(gl.INVALID_OPERATION);
> 
> testRendering();
> 
> // Validate new resources created in testRendering().
> testResources(gl.NO_ERROR);
> 
> testExtensions();
> 
> debug("");
> }
> 
> Our Webkit Nightly Build  fails 
> shouldBeNull("OES_vertex_array_object.createVertexArrayOES()")
> which it should fail , however khronous test case suite expects it to PASS , 
> adn i tested this on chrome on windows, that passes :(
> 
> 
> Kindly put some light here..
> regards
> rsadhu
> 
> 
> regards
> RSadhu
> ___
> 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] Determining the device pixel density of target device

[Dean Jackson]

Greetings AgentX, if that is your real name,

On 5 Mar 2014, at 3:59 pm, AgentX  wrote:

> I was working with *responsive images* in Webkit and I came across this
> *‘deviceScaleFactor’* attribute with determines the pixel density on the
> target device.
> I was unable to find out how does Webkit determine it, that is which
> functions does it use and where can I find them in the Source Code? All I
> was able to find was that it used a function *‘page->deviceScaleFactor()’*
> which somehow returned the scale factor but I was unable to find the exact
> function which actually computes the scale factor.
> 
> Any help here would be highly appreciated!!

As the longer email response suggested, the deviceScaleFactor is initialised
by the hosting application. For example, in WebKit1 on OS X, you can see it 
set in WebView.

WebKit itself does not detect the hardware scaling factor.

Dean

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

[webkit-dev] remove ENABLE(REQUEST_ANIMATION_FRAME)

[Dean Jackson]

Does anyone still build with requestAnimationFrame disabled?

Dean

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

Re: [webkit-dev] remove ENABLE(REQUEST_ANIMATION_FRAME)

[Dean Jackson]

Thanks. In which case I plan to remove the guard in a day or so. Speak up now 
if you object.

(And to be perfectly clear, I’m not removing requestAnimationFrame itself :)

Dean

On 19 Mar 2014, at 10:54 am, 송진우  wrote:

> It is enabled in EFL port. :)
> 
> Jinwoo
> 
> 2014년 3월 19일 수요일, Dean Jackson님이 작성한 메시지:
> Does anyone still build with requestAnimationFrame disabled?
> 
> 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] support for navigator.cores or navigator.hardwareConcurrency

[Dean Jackson]

On 6 May 2014, at 11:13 am, Rik Cabanier  wrote:

> On Mon, May 5, 2014 at 5:52 PM, Simon Fraser  wrote:
> It allows attackers to know even more about my system, exposing more data for 
> fingerprinting.
> 
> People can already approximate this today. Approximations are fuzzy so this 
> might hurt performance if you're not a popular platform or change how the 
> browser implements workers.

There is a difference between approximation and clear detection. During 
discussion of a related feature on the WebGL list (for exposing the GPU 
information to the page), I noted at the time that it would allow any page in 
the world to detect you'd spent X thousand dollars on a Mac Pro in the last 30 
days. Being able to detect the number of cores provides more info - e.g. you 
spent X + Y thousand dollars for the upgrade.

"Let's not show that user ads for vacations in Compton... let's show them the 
Bahamas instead."

>  
> Do you really want a page to know that you have a  fancy-pants 24-core Mac 
> Pro rather than a little Mac mini?
> 
> Yes!
> If I have 24 cores ready to do work and the page can put them to use, I would 
> like it to do so.
> At the same time, if I just have a old mac mini, I don't want the page to 
> launch 24 workers as that will exhaust my memory and cause contention. 

But as Oliver said, maybe I don't want the page to use all cores.

Dean



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

Re: [webkit-dev] WebCore GPU module

[Dean Jackson]

The Loop-Blinn code is dead and should be removed from WebKit. I believe Ken 
Russell implemented it to help with some Chrome/Skia drawing performance, but 
since then Skia itself updated to use a similar GPU-accelerated approach.

Dean

On 18 Jun 2014, at 6:07 pm, Michael IV  wrote:

> Hi All.I have been investigating into WebKit text rendering details and I 
> found Loop-Blinn implementation in GPU directory of WebCore.I have tested it 
> and it kind of works ok for convex shapes rendering which probably should be 
> ok for text glyphs outline as well.
> But I have got a couple of question regarding this module:
> 1)Is it used by the browsers to render text or 2d shapes?
> 2)Is it actually ready for real-life usage?
> 3)How anti  aliasing is handled?I mean ,I found that only curves are 
> anti-aliased(internally by the shader) but the straight line outlines need 
> proper MSAA which can be pretty expensive or even unavailable  on some 
> platforms.
> 
> Also I found a bug: when drawing a path with two overlapping convex shapes 
> ,the hole created on the overlap region which is aliased.
> -- 
>  
> ___
> 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] FeatureDefines.h and .xcconfig

[Dean Jackson]

Hi floks,

Things are a bit confusing in the OS X and iOS build configurations because we 
have both a FeatureDefines.h and a set of .xcconfig files, often defining the 
same thing, and sometimes inconsistently (or at least I've made the mistake of 
turning a feature off in one place when the other place turned it back on).

Obviously it would be good to have only one location for feature enabling.

While FeatureDefines.h says "Use this file to list _all_ ENABLE() macros" it 
also says "The feature defaults in this file are only taken into account if the 
(port specific) build system has not enabled or disabled a particular feature", 
which is not true.

My proposal is to stop using FeatureDefines.h for the Apple ports (*) and move 
completely to .xcconfig files. 

Notes:

- Some scripts launched by Xcode might use the ENABLE_WHATEVER environment 
variables (which FeatureDefines.h can't provide)

- The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 to 
disable a feature, rather than just leaving it blank.

- We'd have to change from #ifdef to #if in places.

- You'd always have to edit 4 files to toggle a feature :(

- Generating the FeatureDefines.xcconfig from FeatureDefines.h might be cool, 
but we have a fair amount of release-specific logic in there (e.g. only enabled 
on 10.9).

Is this a terrible idea? Please suggest a better one!

Dean

(*) I think Apple's Windows port should probably continue with FeatureDefines.h 
because it doesn't use Xcode.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] FeatureDefines.h and .xcconfig

[Dean Jackson]

Just answering this bit because the consensus seems to be to go for the single 
header file.

> On 7 Aug 2014, at 9:57 pm, Laszlo Gombos  wrote:
> 
> > While FeatureDefines.h says "Use this file to list _all_ ENABLE() macros" 
> > it also says "The feature defaults in this file are only taken into account 
> > if the (port specific) build system has not enabled or disabled a 
> > particular feature", which is not true.
> 
> Can you elaborate on why this is not true or perhaps suggest better wording ? 
> Setting any ENABLE_FEATURE_NAME macro to an empty string in xcconfig is 
> explicitly disabling a feature in the build system (see also the comment in 
> e.g. WebCore/Configurations/FeatureDefines.xcconfig)

It doesn't explicitly disable it.

If the .xcconfig says:

ENABLE_FEATURE_NAME=;

Xcode will start a build without that flag defined at all (as an environment 
variable). Notice that the last line in the .xcconfig is FEATURE_DEFINES = 
 and the empty string won't provide any data here.

Then FeatureDefines.h comes along and says:

#if !defined(ENABLE_FEATURE_NAME)
#define ENABLE_FEATURE_NAME 1
#endif

Dean


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

Re: [webkit-dev] FFT normalization in RealtimeAnalyser

[Dean Jackson]

Fixed in r172816.

Dean

> On 15 Aug 2014, at 1:56 am, Info  wrote:
> 
> This seems to be a bug... that has been fixed in Chromium: see 
> chromium\src\third_party\WebKit\Source\modules\webaudio
> 
> 
> Zitat von Info :
> 
>> In order to understand the idiotic differences between the data ranges of 
>> the AnalyzerNode's getFloatFrequencyData() and getByteFrequencyData() APIs I 
>> finally found myself analyzing the WebKit sources: 
>> https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/webaudio/RealtimeAnalyser.cpp
>> 
>> What surprises me there is the:
>>const double magnitudeScale = 1.0 / DefaultFFTSize;
>> which is used to normalize the FFT results (see 
>> RealtimeAnalyser::doFFTAnalysis()).
>> 
>> Should the correct scaling factor not rather be: 2/actualFftSize?
>> 
>> 
>> ___
>> 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] Easy bugs for grab

[Dean Jackson]

FWIW, I've set a personal goal to unprefix one thing a week, until it gets hard 
:)

If you want to unprefix something, let me know and I'll help (and count your 
work towards my goal!!)

Dean

> On 23 Sep 2014, at 6:28 pm, Benjamin Poulain  wrote:
> 
> Hello WebKittens,
> 
> From time to time, people ask for easy bugs to fix.
> 
> Looking at various specs, I see some new features and easy fixes available. 
> For example:
> -Unprefix cursor zoom-in and zoom-out (easy): 
> http://www.w3.org/TR/css3-ui/#cursor
> -Element.closest (easy): https://dom.spec.whatwg.org/#dom-element-closest
> -Fix the visualization of :nth-child(An+B of selector) in the Inspector 
> (probably easy).
> -Unprefix your favorite CSS property (easy to hard depending on the property).
> -etc, etc.
> 
> If you want to work on an amazing opensource project, here is an opportunity 
> to get started. Shoot me an email if you want to implement one of the ideas 
> above.
> 
> If nobody wants those, I'll just fix them :)
> 
> Benjamin
> ___
> 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] Removing ENABLE guard for @supports (CSS3_CONDITIONAL_RULES)

[Dean Jackson]

We've had support for @supports for a while. I'm planning to remove the 
compile-time guard for the feature.
(Note: Safari on iOS 8 and the public Yosemite builds currently have it turned 
off)

Does anyone disagree?

https://bugs.webkit.org/show_bug.cgi?id=137571

Dean

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

[webkit-dev] CSS4 Media Queries

[Dean Jackson]

Hi floks,

I'm going to start implementing a small part of CSS4 Media Queries. I'll put it 
behind a feature flag.

I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
Apple wants to discuss it at the W3C TPAC meetings. We don't have any intention 
to ship the feature yet - it's just for experimentation and evaluation. I 
suggest other ports disable it if they plan on releasing from trunk.

Dean

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

Re: [webkit-dev] CSS4 Media Queries

[Dean Jackson]

> On 18 Oct 2014, at 10:55 am, Dean Jackson  wrote:
> 
> I'm going to start implementing a small part of CSS4 Media Queries. I'll put 
> it behind a feature flag.
> 
> I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
> Apple wants to discuss it at the W3C TPAC meetings. We don't have any 
> intention to ship the feature yet - it's just for experimentation and 
> evaluation. I suggest other ports disable it if they plan on releasing from 
> trunk.

I should have added that I have no idea how to actually implement it on other 
platforms, or if screen inversion is supported. So it won't evaluate to true 
until there is platform code backing it anyway.

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

Re: [webkit-dev] CSS4 Media Queries

[Dean Jackson]

> On 23 Oct 2014, at 5:08 pm, Tab Atkins Jr.  wrote:
> 
> On Fri, Oct 17, 2014 at 4:55 PM, Dean Jackson  wrote:
>> Hi floks,
>> 
>> I'm going to start implementing a small part of CSS4 Media Queries. I'll put 
>> it behind a feature flag.
>> 
>> I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
>> Apple wants to discuss it at the W3C TPAC meetings. We don't have any 
>> intention to ship the feature yet - it's just for experimentation and 
>> evaluation. I suggest other ports disable it if they plan on releasing from 
>> trunk.
> 
> I've put MQ stuff related to the inversion/high-contrast/etc on the
> agenda wiki, so it'll definitely be discussed.

As a followup, inverted-colors and monochrome are now implemented on Apple 
ports. I ended up not using a prefix or feature flag because I’m hoping that 
there won’t be any breaking changes.

Dean

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

Re: [webkit-dev] Unprefixing intrinsic size keywords (-webkit-min-content et al)

[Dean Jackson]

> On 7 Aug 2015, at 2:44 AM, Christian Biesinger  
> wrote:
> 
> Hi all!
> 
> We (blink) would like to unprefix the intrinsic sizing keywords:
> https://drafts.csswg.org/css-sizing/#width-height-keywords
> 
> We support them for widths and for heights (though they all do the
> same thing for heights)
> 
> We were wondering what Webkit's plan for those keywords is -- are you
> also interested in unprefixing? Are you happy with the keywords as
> specced? Would you rather stop supporting them?

Is there a test suite?

I think WebKit should unprefix these keywords.

Dean


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

Re: [webkit-dev] Unprefixing hyphens property?

[Dean Jackson]

> On 26 Jan 2016, at 2:53 AM, Michael Catanzaro  wrote:
> 
> Mozilla has unprefixed the CSS hyphens property as of Firefox 43. Is
> there any interest in unprefixing it for WebKit?

We're interested in unprefixing everything, but we generally like
to know if:

- there is good test coverage (e.g. the web-platform-tests)
- we pass a lot of the tests

Dean

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

Re: [webkit-dev] About unprefixing CSS Grid Layout (implementation status summary included)

[Dean Jackson]

> On 28 Apr 2016, at 4:28 AM, Sergio Villar Senin  wrote:
> 
> On 27/04/16 17:59, Simon Fraser wrote:
>>> On Apr 27, 2016, at 4:39 AM, Manuel Rego Casasnovas  wrote:
>>> 
>>> Hi,
>>> 
>>> as announced yesterday it seems that the WebKit prefixing policy has
>>> been updated [1].
>>> 
>>> Right now CSS Grid Layout implementation is prefixed in WebKit and
>>> behind a compilation flag.
>>> We'd like to ask about the possibility to unprefix it and put it behind
>>> a runtime flag (probably removing the compilation flag too).
>> 
>> I approve of this proposal.
>> 
>> Simon
> 
> Awesome. We'll unprefix it ASAP (adding the runtime flag and removing
> the build one).

Please leave the build flag around. We probably need a bigger discussion
on this, but for now we should have both a runtime flag and a build flag
just in case a browser ships and doesn't want the feature compiled at all
(reducing binary size).

Dean

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

Re: [webkit-dev] canvas and sRGB

[Dean Jackson]

> On 3 May 2016, at 7:04 AM, Rik Cabanier  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser  > wrote:
>> On May 2, 2016, at 1:45 PM, Rik Cabanier > > wrote:
>> 
>> All,
>> 
>> with the release of DCI-P3 screen, WebKit began supporting the display of 
>> high gamut images.
>> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
>> untouched on the new displays.
>> 
>> However, if you try do do any sort of canvas manipulation, you will see that 
>> the colors are being compressed to sRGB and you will lose the depth of the 
>> color.
>> 
>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
> 
> No, this was a deliberate choice. We can't change author expectations for 
> what getImageData() return.
> 
> Now we see different visual output which is also not what an author expects 
> :-(

Since there is no way to create a canvas element with pixel data that is 
interpreted to be in anything other than sRGB, this behaviour seems expected to 
me. I'm not sure what else could happen? We couldn't magically make all the 
canvas elements in the page use P3. If we did that, they wouldn't match the CSS 
content.

The fix is coming: a way to tag the colorspace of the canvas element.

Dean

> 
> Can you elaborate what is unexpected with getImageData? Is it that css "red" 
> no longer returns 100% red pixels?
>> If this is as-designed, how can we work around this limitation?
> 
> With possible future enhancements to the canvas spec that allow authors to 
> request backing store with a different format and/or color profile.
>> 
>> PS
>> I asked the same question on WhatWG. [2]
>> 
>> 
>> 1: 
>> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
>>  
>> 
>> 2: 
>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html 
>> 
> Simon
> 
> 
> 
> ___
> 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] canvas and sRGB

[Dean Jackson]

> On 3 May 2016, at 8:10 AM, Rik Cabanier  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 2:59 PM, Dean Jackson  <mailto:d...@apple.com>> wrote:
> 
>> On 3 May 2016, at 7:04 AM, Rik Cabanier > <mailto:caban...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 1:58 PM, Simon Fraser > <mailto:simon.fra...@apple.com>> wrote:
>>> On May 2, 2016, at 1:45 PM, Rik Cabanier >> <mailto:caban...@gmail.com>> wrote:
>>> 
>>> All,
>>> 
>>> with the release of DCI-P3 screen, WebKit began supporting the display of 
>>> high gamut images.
>>> Specifically, if you have an image with a DCI-P3 profile, its pixels render 
>>> untouched on the new displays.
>>> 
>>> However, if you try do do any sort of canvas manipulation, you will see 
>>> that the colors are being compressed to sRGB and you will lose the depth of 
>>> the color.
>>> 
>>> Was it an oversight to always create the canvas imagebuffer in sRGB? [1]
>> 
>> No, this was a deliberate choice. We can't change author expectations for 
>> what getImageData() return.
>> 
>> Now we see different visual output which is also not what an author expects 
>> :-(
> 
> Since there is no way to create a canvas element with pixel data that is 
> interpreted to be in anything other than sRGB, this behaviour seems expected 
> to me. I'm not sure what else could happen? We couldn't magically make all 
> the canvas elements in the page use P3. If we did that, they wouldn't match 
> the CSS content.
> 
> I don't see why that would be. CSS colors and tagged/untagged images would be 
> color corrected while being drawn just like it happens in HTML.
> get/putImageData would of course be uncorrected as it works on raw pixels.

That's the problem. If we did what you suggest a paint with rgba(255, 0, 0, 1) 
would not be the same as putting [255, 0, 0, 255] into the buffer via 
ImageData, and no page in the world would expect that. And there would also be 
no way to paint into the canvas to match colours outside of sRGB.

I think we did the right thing for now. The complete solutions are coming.

Dean


>  
> The fix is coming: a way to tag the colorspace of the canvas element.
> 
> That's great! Do you have an idea how far off that proposal is?
>  
>> Can you elaborate what is unexpected with getImageData? Is it that css "red" 
>> no longer returns 100% red pixels?
>>> If this is as-designed, how can we work around this limitation?
>> 
>> With possible future enhancements to the canvas spec that allow authors to 
>> request backing store with a different format and/or color profile.
>>> 
>>> PS
>>> I asked the same question on WhatWG. [2]
>>> 
>>> 
>>> 1: 
>>> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73
>>>  
>>> <https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73>
>>> 2: 
>>> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html
>>>  
>>> <https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html>
>> Simon
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <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] REQUEST_ANIMATION_FRAME on all ports?

[Dean Jackson]

Do the EFL and GTK ports always enable this feature? If so, I'm going to remove 
the compile flag.

Dean

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

Re: [webkit-dev] REQUEST_ANIMATION_FRAME on all ports?

[Dean Jackson]

> On Jun 8, 2016, at 2:23 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 08.06.2016, 23:59, "Dean Jackson" :
>> Do the EFL and GTK ports always enable this feature? If so, I'm going to 
>> remove the compile flag.
> 
> While I'm not opposed to this change, it looks like its maintenance cost is 
> near zero.

I think we should remove guards for features that are (now) core to the Web.

Dean

> Last time I was building with it disabled it was not broken, though it didn't 
> receive any compilation fixes for at least 2 years!
> 
> https://bugs.webkit.org/show_bug.cgi?id=155882
> https://lists.webkit.org/pipermail/webkit-dev/2014-March/026366.html
> 
> -- 
> Regards,
> Konstantin

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

[webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

[Dean Jackson]

I propose we make it official that the Web Inspector Coding Style is what must 
be used for all JavaScript and CSS that count as source code in the project.
https://trac.webkit.org/wiki/WebInspectorCodingStyleGuide

Now that JavaScript is used in more places (JS builtins, some parts of the DOM, 
media controls) it would be nice to make it all consistent. Note that the page 
above can't decide if it is just JS or both JS and CSS, but I think it should 
be both.

This would not include LayoutTests or PerformanceTests. It's the wild west in 
there - you can do whatever you want.


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

Re: [webkit-dev] CSS Animations and SVG

[Dean Jackson]

On 27/02/2009, at 2:57 AM, Harry Underwood wrote:

Do the CSS Animations, Transitions, Transforms and Transforms 3D  
modules that are being proposed by Apple and currently included in  
WebKit inclusive of the SVG spec, or is it exclusive to interaction  
with xHTML as far as stylesheet-markup interaction is concerned? And  
is the status quo subject to change in this regard?


We have plans to allow transitions on SVG properties:

https://bugs.webkit.org/show_bug.cgi?id=21586

I predict that bug will probably get Animations working at the same  
time (in the engine there isn't a huge difference).


Of course that will only work for SVG's style properties, not the  
attributes (like cx/cy for the positioning of a circle).


Transforms and 3D Transforms were written to be as compatible with SVG  
as possible. 2D transforms could reasonably apply to SVG (except the  
SVG specification says transform is an attribute, not a property). 3D  
transforms are slightly trickier because they could change the SVG  
rendering model for drawing order. The SVG WG at W3C are currently  
looking into this - we hope they come up with something that is  
compatible with what we have proposed.


I wanted to ask this because, if CSS Animations could be combined  
with SVG markup, it would really change the definition of web  
animation from something that is best left scripted to something  
that could be styled.


SVG can also use SMIL for declarative animation, so you don't have to  
always resort to scripting. Some of that is already implemented in  
WebKit. Hopefully we can combine/sync the two animation systems  
sometime soon. That would need to be specified (eg which animation  
wins? this is what the SVG list response was getting at).


Dean


Plus, for those WYSIWYG HTML editors which may come to support this  
module given the success of WebKit's propogation, it would mean that  
people could create animations on their web pages using HTML editor 
+Inkscape, rather than HTML editor+Ikivo Animator (in other words,  
less need for shareware to do this job).


I asked about this on the SVG Developers mailing list, but one of  
the more frequent denizens stated that he and others on the list  
felt that the draft was too underdefined to tell about interactions  
between SVG and CSS Animations. http://article.gmane.org/gmane.text.xml.svg.devel/45508


Rayne
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit GPU rendering possibility

[Dean Jackson]

> On 5 Nov. 2016, at 12:34 am, Rogovin, Kevin  wrote:
> 
> One question, what happens with WebGL 2.0 support on WebKit? I ask because 
> WebGL 2.0 is essentially OpenGL ES 3.x for JavaScript.

We've started on a WebGL 2.0 implementation.

Dean

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

Re: [webkit-dev] Experimental features enabled at runtime

[Dean Jackson]

> On 6 Nov. 2016, at 10:03 am, Ryosuke Niwa  wrote:
> 
> I DO want to enable experimental features to be enabled in Safari Technology 
> Preview and WebKit nightly builds by default because that's sort of the whole 
> point of having those versions of Safari in the first place.

I might be the only one with this point of view (and it explains the confusion 
since I added the code), but "Experimental" means exactly that: it isn't ready 
to be enabled by default. If it can be enabled by default, it isn't 
experimental.

Safari Technology Preview is meant to be used as a full-time browser. It has to 
be stable. Yes, it has features that haven't yet shipped in main Safari, but 
they should not be dangerous. The idea of the Experimental Features is that 
developers can easily choose to enable them, just like they do on other 
browsers.

I don't understand why we'd pick a different behaviour than Chrome, Firefox, 
etc in this case. Developers understand this situation.

Dean

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

Re: [webkit-dev] WebGL bug related to PNG textures with zero alpha channel

[Dean Jackson]

Looks like we have a bug in premultiplication. We'll look at it.

Dean

> On Dec 12, 2016, at 6:52 AM, Ivan Lyubovnikov  wrote:
> 
> Hi, all! Can anyone take a look at the bug related to WebGL and PNG textures: 
> https://bugs.webkit.org/show_bug.cgi?id=165297? We've been able to reproduce 
> this issue for a long time and it makes it a bit difficult to use that 
> textures under iOS - this usually requires some workarounds/hacks.
> Thanks in advance!
> 
> Ivan.
> ___
> 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] Removing support for CSS regions

[Dean Jackson]

I've been told that Amazon's Kindle Cloud Reader uses CSS Regions if available, 
and gets a significant performance boost. It has a fallback though.

Also, it would be worth checking at least Apple's iBooks store for any content 
that might have used regions. It would be a shame if purchased books stopped 
working :)

Dean


> On 31 Jul 2017, at 10:49, Andreas Kling  wrote:
> 
> Hi folks,
> 
> Some time has passed, and it seems that adoption of CSS regions on the web is 
> not gonna happen.
> 
> Blink has long since removed their support.
> Firefox never supported it AFAIK.
> (The new) IE has some amount of support behind a prefix, but no plans to 
> unprefix AFAIK.
> 
> I think it’s time we remove the code from WebKit, and relieve ourselves of 
> the maintenance burden.
> This should also open up numerous opportunities for clean-up and optimization.
> 
> If you know of any reason to keep the feature, such as a major website or 
> WebKit client depending on it, do speak up now!
> 
> The removal work will be tracked in this bug:
> https://bugs.webkit.org/show_bug.cgi?id=174978
> 
> Cheers,
> kling
> ___
> 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] Opengl support in webkit

[Dean Jackson]

> On 21 Jul 2017, at 13:47, Nagendra K  wrote:
> 
> Hi ,
> 
> Does WebKit engine mandate to use any version of opengl?
> Can we link any opengl which my platform has.

As long as your OpenGL is compatible with OpenGL 4.0 and above, or OpenGL ES 
2.0 and above, I think you'll be fine.

Dean

>  
> Could see that for opengles2 is there with a flag in if condition and else 
> condition to gl.h.
> So if else is used, can I link to any opengl version which my platform has ?
> 

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

Re: [webkit-dev] WebKit opengl

[Dean Jackson]

> On 19 Jul 2017, at 12:21, Nagendra K  wrote:
> 
> Current build of WebKit using opengl and with custom port, all apps will 
> directly use the opengl calls to draw, making the opengl independent of 
> WebKit.
> So if I upgrade the WebKit, will the latest WebKit require opengl for any of 
> the new features or can we use opengl delinking WebKit.

I don't understand what you are asking, sorry.

It's possible to make a port of WebKit that doesn't rely on OpenGL. I think the 
Windows port is one example. Technically Apple's iOS/macOS ports only directly 
require OpenGL for WebGL support.

Dean


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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Dean Jackson]

> On 24 Jul 2017, at 22:44, Brian Burg  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 
> .

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
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebVR on WebKit

[Dean Jackson]

> On 2 Aug 2017, at 19:55, Sergio Villar Senin  wrote:
> 
> 
> Our main interest is to eventually have some implementation working on
> WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
> platform work that needs to be done as well. Our initial idea would be
> to use the OpenVR API as Valve released a Linux version of their SDK
> some months ago. Looks like a safe bet as other vendors like Firefox or
> Chromium already include it in their trees as third party.

I agree with the idea to assume use of the OpenVR SDK at the moment. It
is the only major VR SDK that is available for macOS, Linux and Windows.

So maybe our platform API should be very similar to the OpenVR API?
I haven't looked at other SDKs like Oculus, but hopefully it isn't too
different.

Dean


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