On Wed, May 23, 2012 at 2:59 PM, Jacob Goldstein wrote:
> As a side note to this discussion, there is talk in the W3C community
> regarding their test approval process. At the recent working group
> meetings in Germany the idea was floated to simply approve all tests that
> are currently waiting
On May 23, 2012, at 3:13 PM, Dirk Pranke wrote:
> On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak wrote:
>>
>> Are you concerned just about the actual pixel results or also about keeping
>> render tree dumps up to date?
>
> Both are more maintenance than a text-only test. In my experience
On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak wrote:
>
> Are you concerned just about the actual pixel results or also about keeping
> render tree dumps up to date?
Both are more maintenance than a text-only test. In my experience,
maintaining pixel tests is more expensive, but I also don't
On 5/23/12 2:30 PM, "Maciej Stachowiak" wrote:
>
>On May 23, 2012, at 2:16 PM, Dirk Pranke wrote:
>
>> On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa wrote:
> The only sane argument I've heard so far to gate pixel tests is that
>the
> correctness of such tests need to be manually i
On May 23, 2012, at 2:16 PM, Dirk Pranke wrote:
> On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa wrote:
The only sane argument I've heard so far to gate pixel tests is that the
correctness of such tests need to be manually inspected, which requires
a
lot of manual labor and i
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa wrote:
>> > The only sane argument I've heard so far to gate pixel tests is that the
>> > correctness of such tests need to be manually inspected, which requires
>> > a
>> > lot of manual labor and is very error prone.
>>
>> I'm assuming the above incl
On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke wrote:
>
> Not so: if the tests we had had 100% coverage, then importing more
> tests would buy us nothing, but getting rid of the existing tests
> would be quite unfortunate.
We certainly don't have 100% test coverage.
Clearly adding tests incurs so
Dirk, my apologies, I was on travel the week you replied and missed your
message. I found it and will review / update now.
On 5/23/12 1:25 PM, "Dirk Pranke" wrote:
>On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa wrote:
>> As I have said in the past, we should just import all tests, and treat
On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa wrote:
> As I have said in the past, we should just import all tests, and treat
> non-text, non-ref tests as pixel tests. If we wanted to reduce the number of
> pixel tests we import, then we should submit those patches to W3C instead of
> directly su
I agree. If nothing else, getting W3C tests into the WebKit repository will
help catch regressions.
From: Ryosuke Niwa mailto:rn...@webkit.org>>
To: Jacob Goldstein mailto:jac...@adobe.com>>
Cc: WebKit Development
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Importing W3C test
Hi,
While taking a look into bug 83419 (about fast/transforms/scrollIntoView-
transformed.html) I faced with the following render issue:
When using Element::scrollInToView(true) on blocking elements that have bigger
child elements with margins webkit and Firefox show different results.
I attach
As I have said in the past, we should just import all tests, and treat
non-text, non-ref tests as pixel tests. If we wanted to reduce the number
of pixel tests we import, then we should submit those patches to W3C
instead of directly submitting them to WebKit.
In general, I don't buy the argument
At the WebKit contributor's meeting in April, we discussed a process for
importing third party tests into the WebKit repository (specifically, from the
W3C test repository).
I documented the process that we came up with at the meeting on the WebKit
wiki, here:
http://trac.webkit.org/wiki/Import
Hey, I'd love to attend but I'm going to be away on vacation at that time.
Maybe next time.
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
on behalf of Gavin Peters (蓋文彼紱斯) [gav...@webkit.org]
Sent: Friday, May 18, 2012 3:46 AM
To
Hi,
Have you some news about dfg optimisations? what are you planing, what have
you now or what is your current work ?
Currently we do not have either LICM, or loop peeling, or GCSE. We do have
> a patch that implements LICM, but we are letting it simmer for now because
> under the current DFG IR,
15 matches
Mail list logo