Chris Rogers | 2 Feb 00:17 2010
Picon

Heads up for audio changes

Hey guys,


Just so nobody will be surprised, over the next weeks I'm going to start landing some new code for an audio engine.
This code will primarily live in a new directory WebCore/platform/audio and will implement some new audio features such as:

* scheduled sound playback for sample-accurate musical applications
* spatialized audio such as what is found in OpenAL (source/listener-based, distance effects, sound cones, doppler-shift, ...)
* a convolution engine for a wide range of linear effects, especially very high-quality room effects (concert halls, etc.)
* realtime analysis / music visualizer support
* a modular effects architecture (still being fleshed out)
* granular effects

I've been talking with Eric Carlson, Simon Fraser, Chris Marrin, Dean Jackson to work out some API issues.  And as soon as this all gels, I'll be landing the IDL files.  In the meantime, there's quite a lot of fundamental engine code which will not be affected by the API which I hope to land in the near future.

Best Regards,
Chris Rogers
 
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Eric Seidel | 2 Feb 01:03 2010

Re: Reviewers Needed!

We hit over 100 again today. :(  I just went through the whole queue
again and we're back to 80, but many of them I can't review myself.

Any help is most appreciated.

-eric

On Tue, Jan 26, 2010 at 3:10 PM, Eric Seidel <eric <at> webkit.org> wrote:
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>
> There are 30 bugs fewer than when I started an epic review-them-all
> two hours ago, but we still need more help!
>
> 71 patches up for review.  Please knock a few off the list.  An r-
> with comments is better than a rotten patch.
>
> -eric
>
Adele Peterson | 2 Feb 01:05 2010
Picon

Re: Reviewers Needed!

Maybe we can take another cut at breaking this into groups so its easier for people to scan for bugs they feel
comfortable reviewing.

On Feb 1, 2010, at 4:03 PM, Eric Seidel wrote:

> We hit over 100 again today. :(  I just went through the whole queue
> again and we're back to 80, but many of them I can't review myself.
> 
> Any help is most appreciated.
> 
> -eric
> 
> On Tue, Jan 26, 2010 at 3:10 PM, Eric Seidel <eric <at> webkit.org> wrote:
>> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>> 
>> There are 30 bugs fewer than when I started an epic review-them-all
>> two hours ago, but we still need more help!
>> 
>> 71 patches up for review.  Please knock a few off the list.  An r-
>> with comments is better than a rotten patch.
>> 
>> -eric
>> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Eric Seidel | 2 Feb 01:05 2010

Re: commit-queue is behind

If you're wondering why your cq+'d patch hasn't landed, it's because
we're behind again.  21 patches in the queue.  Again, mostly due to
the tree being red for an extended period this weekend (and today).

The queue should catch up over night.

-eric

On Wed, Jan 27, 2010 at 1:31 PM, Eric Seidel <eric <at> webkit.org> wrote:
> The commit queue caught up over night, and is operating normally
> again.  (aka if build.webkit.org is green, then your patch should be
> landed within 15 minutes of setting cq+)
>
> Thanks for your patience.
>
> -eric
>
> On Wed, Jan 27, 2010 at 3:12 AM, Eric Seidel <eric <at> webkit.org> wrote:
>> The tree was torched again this evening. :(  The builders got way way
>> way behind.  I cleared the slow ones just now.  I expect them to roll
>> green and the commit-bot to start landing while we sleep. :)
>>
>> -eric
>>
>> On Tue, Jan 26, 2010 at 5:55 PM, Eric Seidel <eric <at> webkit.org> wrote:
>>> Sorry, the commit-queue got behind today (currently 19 patches in the
>>> queue) due to the bots being red much of the day and whole bunch of
>>> reviewing. :)
>>> http://build.webkit.org/console
>>>
>>> It should catch up over night.
>>>
>>> Thanks for your patience.
>>>
>>> -eric
>>>
>>
>
Evan Martin | 2 Feb 01:06 2010

Re: Reviewers Needed!

On Mon, Feb 1, 2010 at 4:03 PM, Eric Seidel <eric <at> webkit.org> wrote:
> We hit over 100 again today. :(  I just went through the whole queue
> again and we're back to 80, but many of them I can't review myself.

I feel a lot of pity for you, that your project is so successful that
you have more contributions than you have time to look through them
all.  ;)
Oliver Hunt | 2 Feb 01:08 2010
Picon

Re: Reviewers Needed!

A significant number of the patches available are port specific (and some have been there for a while) so it
would be good if reviewers for those ports could go through the entire review queue and deal with all the
patches related to your port.

--Oliver

On Feb 1, 2010, at 4:03 PM, Eric Seidel wrote:

> We hit over 100 again today. :(  I just went through the whole queue
> again and we're back to 80, but many of them I can't review myself.
> 
> Any help is most appreciated.
> 
> -eric
> 
> On Tue, Jan 26, 2010 at 3:10 PM, Eric Seidel <eric <at> webkit.org> wrote:
>> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>> 
>> There are 30 bugs fewer than when I started an epic review-them-all
>> two hours ago, but we still need more help!
>> 
>> 71 patches up for review.  Please knock a few off the list.  An r-
>> with comments is better than a rotten patch.
>> 
>> -eric
>> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Leif Arne Storset | 2 Feb 17:17 2010

Support for SVG preserveAspectRatio in <img>

Hello,

While doing some SVG-related work over here I discovered that WebKit's
rendering of SVG in <img> tags differs from Opera's. Since WebKit and
Opera to my knowledge are the only engines that currently support SVG in
<img> 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 <img> 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 <img>, 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 <img> 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
<svg:image> (that is: <image> elements inside of an <svg>), pAR seems to
be applied as per the spec.

We believe that not applying the pAR on svg in <img> 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
Attachment (img.zip): application/zip, 14 KiB

viewBox? preserve­Aspect­Ratio <img> <object> No viewBox none meet slice viewBox none meet slice

No size specified

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Dean Jackson | 2 Feb 19:39 2010

Re: Support for SVG preserveAspectRatio in <img>

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 <img> tags differs from Opera's. Since WebKit and
> Opera to my knowledge are the only engines that currently support SVG in
> <img> 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 <img> 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 <img>, 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 <img> 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
> <svg:image> (that is: <image> elements inside of an <svg>), pAR seems to
> be applied as per the spec.
> 
> We believe that not applying the pAR on svg in <img> 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<img.zip><chrome-pAR.png><opera-pAR.png><preserveAspectRatio.html>_______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Eric Seidel | 2 Feb 21:04 2010

Re: Support for SVG preserveAspectRatio in <img>

Definitely a bug.

Some of these are on file, some are not:
http://webkit.org/quality/reporting.html

-eric

On Tue, Feb 2, 2010 at 8:17 AM, Leif Arne Storset <lstorset <at> opera.com> wrote:
> Hello,
>
> While doing some SVG-related work over here I discovered that WebKit's
> rendering of SVG in <img> tags differs from Opera's. Since WebKit and
> Opera to my knowledge are the only engines that currently support SVG in
> <img> 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 <img> 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 <img>, 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 <img> 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
> <svg:image> (that is: <image> elements inside of an <svg>), pAR seems to
> be applied as per the spec.
>
> We believe that not applying the pAR on svg in <img> 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 <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
Lenny Rachitsky | 2 Feb 22:21 2010

Re: Implementing WebTiming as a part of HTML5

I’d like to address the question by Darin, regarding the question of feedback and whether anyone is planning to build something to use this new feature...

I work for a company that sells a web performance monitoring service to Fortune 1000 companies. To give a quick bit of background to the monitoring space, there are two basic ways to provide website owners with reliable performance metrics for their web site/applications. The first is to do active/synthetic monitoring, where you test the site using an automated browser from various locations around the world, simulating a real user. The second approach is called passive or real user monitoring, which captures actual visits to your site and records the performance of those users. This second approach is accomplished with either a network tap appliance sitting in the customers datacenter that captures all of the traffic that comes to the site, or using an “event listener” javascript timer which times the client side page performance and sends it back to a central server.

Each of these approaches has pros and cons. The synthetic approach doesn’t tell you what actual users are seeing, but it consistent and easy to setup/manage. The appliance approach is expensive and misses out on components that don’t get served out of the one datacenter, but it sees real users performance. The client side javascript timing approach gives you very limited visibility, but is easy to setup and universally available. This limited nature of the this latter javascript approach is the crux of why this “Web Timing” draft is so valuable. Website owners today have no way to accurately track the true performance of actual visitors to their website. With the proposed interface additions, companies would finally be able to not only see how long the page truly takes to load (including the pre-javascript execution time), but they’d also now be able to know how much DNS and connect time affect actual visitors’ performance, how much of an impact each image/objects makes (an increasing source of performance issues), and ideally how much JS parsing and SSL handshakes add to the load time. This would give website owners tremendously valuable data is currently impossible to reliably track.
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Gmane