[webkit-dev] JSGlobalData GC collection thread lifetime if webview is recreated without application exit.

2012-05-23 Thread Mayur K
Hi All,
I have been studying the JS execution and noticed that the JSGlobalData is
stored in a static variable and never deleted.
I traced even the windows port and noticed one more thing, that the
JSGlobalData and the Heap class destructor are never called. As it is
static I assume that the JSGlobalData is cleaned up automatically on
process exit.
I realised that this would in turn have an effect if we delete the webview
and recreate it again. The JSGlobalData will still point to the old static
var.

So now to my question : Is it required to delete JSGlobalData and kill the
GC thread if we keep on re-creating the webview again and again without
exiting the process?

Thanks.
--Mayur.

-- 
Symbiangeek,Codekata  Webkitwiki all in one - http://flaminghorns.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] JSGlobalData GC collection thread lifetime if webview is recreated without application exit.

2012-05-23 Thread Geoffrey Garen
 So now to my question : Is it required to delete JSGlobalData and kill the GC 
 thread if we keep on re-creating the webview again and again without exiting 
 the process?

No.

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


Re: [webkit-dev] DFG optimizations

2012-05-23 Thread blake fiddler
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, it is somewhat of a complicated beast. My main
 concern is just bug tail, due to the various stunts that the current LICM
 patch has to do to fool the DFG into moving code between basic blocks.

 We're fixing that by steadily moving the DFG IR towards SSA. Once we
 finish that, I think we'll implement either LICM or peeling+GCSE based on
 whatever appears to be the simplest. We already know that LICM is a pure
 performance win; but on the other hand, GCSE is likely to be more generic.
 I tend to think that extending our current CSE framework to support some
 maximally-profitable subset of GCSE will not be terribly difficult.

 We don't currently have PRE. It's not on my short list of optimizations to
 implement.

 But if we wanted to go down that route, it might be interesting to
 consider something like Van Drunen's GVN-PRE [1]. I have already been
 thinking about implementing GVN; maybe just going straight for GVN-PRE
 would turn out to be easy enough. But it goes without saying that GVN alone
 is a dead-simple optimization compared to Van Drunen's work, and, even
 according to his performance results, PRE is a *tiny* win over simpler
 redundancy elimination optimizations.

 -Filip

 [1] ftp://ftp.cs.purdue.edu/pub/hosking/papers/a-ssapre.pdf



 On Mar 25, 2012, at 4:59 PM, Nare Karapetyan wrote:

  HI!
 
  There is a discussion about LICM implementation in DFG in one of
 previous posts.
  There it was said that the developers had not decided yet which
 optimization to do: LICM or loop peeling with global CSE.
  So is there any progress in this direction?
 
 
  And about CSE, does it include the partial redundancy elimination (PRE)?
 
 
  --
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.webkit.org/pipermail/webkit-dev/attachments/20120325/a57e47fa/attachment-0001.html
 

 --

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


 End of webkit-dev Digest, Vol 82, Issue 38
 **

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


[webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Jacob Goldstein
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/ImportingThirdPartyTests

It would be great if we could get some feedback on this process.

Once we can finalize the details for how this should function, the effort can 
proceed - scripts can be written to help automate the effort and an actual 
import of select W3C test suites can be performed.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Ryosuke Niwa
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 that adding more pixel tests incurs
more cost than the benefit we get from importing the tests. If that were
the case, we can just get rid of the existing pixel tests we have.

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.

For script-based tests that print PASS/FAIL, it seems better to just check
in *-expected-failure.txt or even -expected.txt files because we'll see
PASS/FAIL in the expected tests themselves.

- Ryosuke

On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein jac...@adobe.com wrote:

 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/ImportingThirdPartyTests

 It would be great if we could get some feedback on this process.

 Once we can finalize the details for how this should function, the effort
 can proceed - scripts can be written to help automate the effort and an
 actual import of select W3C test suites can be performed.

 ___
 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] scrollInToView(true) have different behavior on WebKit and Firefox

2012-05-23 Thread Hugo Parente Lima
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 attached the html file [1] and the render results on Firefox[2] and WebKit[3] 
into the bug, so what's the correct result?

IMO the Firefox behavior seems right, but before trying to fix anything better 
to know if a consensus on what is right exists.

The scrollInToView spec[4] says:

If the align to top flag is set align the top of the border box of the element 
to be scrolled into view with the top of the scrolling box.

[1] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143619
[2] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143620
[3] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143621
[4] http://dev.w3.org/csswg/cssom-view/

Regards,
Hugo Parente Lima

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Jacob Goldstein
I agree.  If nothing else, getting W3C tests into the WebKit repository will 
help catch regressions.

From: Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org
To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com
Cc: WebKit Development 
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Importing W3C tests to webkit

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 that adding more pixel tests incurs more 
cost than the benefit we get from importing the tests. If that were the case, 
we can just get rid of the existing pixel tests we have.

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.

For script-based tests that print PASS/FAIL, it seems better to just check in 
*-expected-failure.txt or even -expected.txt files because we'll see PASS/FAIL 
in the expected tests themselves.

- Ryosuke

On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein 
jac...@adobe.commailto:jac...@adobe.com wrote:
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/ImportingThirdPartyTests

It would be great if we could get some feedback on this process.

Once we can finalize the details for how this should function, the effort can 
proceed - scripts can be written to help automate the effort and an actual 
import of select W3C test suites can be performed.

___
webkit-dev mailing list
webkit-dev@lists.webkit.orgmailto: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] Importing W3C tests to webkit

2012-05-23 Thread Dirk Pranke
On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org 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 submitting them to WebKit.

 In general, I don't buy the argument that adding more pixel tests incurs
 more cost than the benefit we get from importing the tests. If that were the
 case, we can just get rid of the existing pixel tests we have.


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. Clearly adding tests incurs some costs and
probably provides some benefit; the question is when does the cost
exceed the benefit?

As I am not against importing more tests per se, I think this only
makes sense to evaluate on a case-by-case basis.

 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 includes the ongoing maintenance cost of
keeping pixel tests up to date, as well as the cost at the initial
checkin.

There is also the fact that the more tests we have, the more tests we
have to run, and increasing cycle time by itself is a cost to
developer productivity. Of course, it's also potentially the case that
we have to update tests from time to time, although this doesn't
happen often.

Jacob, I gave you a bunch of feedback not long after you published the
initial writeup, but it doesn't look like any of that has been
incorporated?

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Jacob Goldstein
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 dpra...@chromium.org wrote:

On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org 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 submitting them to WebKit.

 In general, I don't buy the argument that adding more pixel tests incurs
 more cost than the benefit we get from importing the tests. If that
were the
 case, we can just get rid of the existing pixel tests we have.


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. Clearly adding tests incurs some costs and
probably provides some benefit; the question is when does the cost
exceed the benefit?

As I am not against importing more tests per se, I think this only
makes sense to evaluate on a case-by-case basis.

 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 includes the ongoing maintenance cost of
keeping pixel tests up to date, as well as the cost at the initial
checkin.

There is also the fact that the more tests we have, the more tests we
have to run, and increasing cycle time by itself is a cost to
developer productivity. Of course, it's also potentially the case that
we have to update tests from time to time, although this doesn't
happen often.

Jacob, I gave you a bunch of feedback not long after you published the
initial writeup, but it doesn't look like any of that has been
incorporated?

-- Dirk

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Ryosuke Niwa
On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke dpra...@chromium.org 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 some costs and probably provides some benefit;
 the question is when does the cost exceed the benefit?


Doing anything incurs some cost. In fact, not adding a test itself incurs a
risk cost of potentially taking regressions in the future that could have
been caught by the test.

As I am not against importing more tests per se, I think this only
 makes sense to evaluate on a case-by-case basis.


Sure. We shouldn't be importing tests that are obviously duplicates of our
existing tests.

 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 includes the ongoing maintenance cost of
 keeping pixel tests up to date, as well as the cost at the initial
 checkin.


I'm not concerned of those. Once the correct expected result is checked in,
it's pretty easy to rebaseline tests per rendering engine changes assuming
people who are rebaselining tests know what they're doing.

There is also the fact that the more tests we have, the more tests we
 have to run, and increasing cycle time by itself is a cost to developer
 productivity.


Sure, but I don't think that's a valid argument for not adding tests
especially since there is no way for us to mechanically test whether two
tests test the same set of features or not (this is an intractable problem
even in its limited form and an undecidable one in its most general form).

Also, using ref test or pixel test, etc... doesn't change the cycle time
significantly so I don't understand what your argument is. Or are you
suggesting that non-ref tests are somehow more redundant than ref tests?
(please give us why).

Of course, it's also potentially the case that
 we have to update tests from time to time, although this doesn't
 happen often.


Because the current process is broken :) In the ideal world, we would be
updating our copy of W3C tests every so often (e.g. every month or so).

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Dirk Pranke
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org 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 includes the ongoing maintenance cost of
 keeping pixel tests up to date, as well as the cost at the initial
 checkin.

 I'm not concerned of those. Once the correct expected result is checked in,
 it's pretty easy to rebaseline tests per rendering engine changes assuming
 people who are rebaselining tests know what they're doing.

You should be concerned; keeping pixel tests up-to-date is clearly a
non-zero cost that only the chromium port thus far has been willing to
bear, and I suspect that the cost of updating baselines is
substantially higher than the cost of the initial review over time
(since it's a recurring cost).

We only have to ask Emil and Levi what the cost of updating all of the
pixel tests were for the subpixel layout test change, or ask the skia
guys how many bug fixes they're reluctant to make because of the cost
of reviewing literally thousands of images that change
inconsequentially for empirical evidence for this.

 There is also the fact that the more tests we have, the more tests we
 have to run, and increasing cycle time by itself is a cost to developer
 productivity.

 Sure, but I don't think that's a valid argument for not adding tests
 especially since there is no way for us to mechanically test whether two
 tests test the same set of features or not (this is an intractable problem
 even in its limited form and an undecidable one in its most general form).

At some point adding more tests will introduce a declining marginal
rate of return in finding more bugs; this is a truism of software
development, and is why *all* software testing efforts stop at some
point (ignoring formal proofs of completeness in model checkers).
Either you don't think this is true, or you think this is true and
we're just not at that point yet.

If you think the latter then we agree, but I don't understand why you
are arguing as if you believe the former.

To repeat myself, I have never said that we shouldn't ever add more
tests, just that we should have a rational process for doing so that
includes looking at what overlap we have with the existing tests and
making sure that adding more tests delivers value. Since you agree at
least that we shouldn't be adding duplicate tests, you clearly agree
with this to some degree, so I'm not sure if you and I have any real
disagreements or if we're just talking past each other.

 Also, using ref test or pixel test, etc... doesn't change the cycle time
 significantly so I don't understand what your argument is. Or are you
 suggesting that non-ref tests are somehow more redundant than ref tests?
 (please give us why).

I am saying that I believe that adding pixel tests incur more cost on
the project than adding ref tests, and since all testing is about cost
vs. benefit, you need to be more careful when adding pixel tests.
Since we actively discourage people from writing pixel tests in favor
of text-only or ref tests, I hardly think this is a controversial
stance.

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Maciej Stachowiak

On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org 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 includes the ongoing maintenance cost of
 keeping pixel tests up to date, as well as the cost at the initial
 checkin.
 
 I'm not concerned of those. Once the correct expected result is checked in,
 it's pretty easy to rebaseline tests per rendering engine changes assuming
 people who are rebaselining tests know what they're doing.
 
 You should be concerned; keeping pixel tests up-to-date is clearly a
 non-zero cost that only the chromium port thus far has been willing to
 bear, and I suspect that the cost of updating baselines is
 substantially higher than the cost of the initial review over time
 (since it's a recurring cost).

Are you concerned just about the actual pixel results or also about keeping 
render tree dumps up to date? We can address the pixel result issue by 
introducing a new test that dumps its render tree but does not do pixel testing.

I think there is a high value to importing standards test suites wholesale, 
even if they overlap with our existing coverage. Picking and choosing subsets 
makes things  more complicated. If there are significant externalities to 
adding particular kinds of tests, I would prefer we mitigate those 
externalities rather than run fewer tests.

Regards,
Maciej

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Jacob Goldstein


On 5/23/12 2:30 PM, Maciej Stachowiak m...@apple.com wrote:


On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org 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 includes the ongoing maintenance cost of
 keeping pixel tests up to date, as well as the cost at the initial
 checkin.
 
 I'm not concerned of those. Once the correct expected result is
checked in,
 it's pretty easy to rebaseline tests per rendering engine changes
assuming
 people who are rebaselining tests know what they're doing.
 
 You should be concerned; keeping pixel tests up-to-date is clearly a
 non-zero cost that only the chromium port thus far has been willing to
 bear, and I suspect that the cost of updating baselines is
 substantially higher than the cost of the initial review over time
 (since it's a recurring cost).

Are you concerned just about the actual pixel results or also about
keeping render tree dumps up to date? We can address the pixel result
issue by introducing a new test that dumps its render tree but does not
do pixel testing.

I think there is a high value to importing standards test suites
wholesale, even if they overlap with our existing coverage. Picking and
choosing subsets makes things  more complicated. If there are significant
externalities to adding particular kinds of tests, I would prefer we
mitigate those externalities rather than run fewer tests.


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 for review (and doing this going forward, e.g. no
longer requiring approval upon submission).

Apparently, not enough people are reviewing tests, and as a result, tests
can linger for months (or longer) before ever being looked at.  Once
browser vendors start implementing features, associated tests will be
revisited for that area.

This has by no means been decided, but something we should consider if it
ultimately does come to fruition.  If W3C tests are no longer
reviewed, this would mean importing tests without any knowledge of their
accuracy - though that will still allow us to catch regressions.



Dirk, I've updated the process on the Wiki page with the feedback you
provided.  I hope I captured it all - I included everything that appeared
to have agreement between you and Ryosuke.  Feel free to modify it
directly if I missed anything, or let me know and I can refine it further.


Jacob



Regards,
Maciej

___
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] Importing W3C tests to webkit

2012-05-23 Thread Dirk Pranke
On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com 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 have any
experience maintaining a non-pixel-test-running port.

 We can address the pixel result issue by introducing a new test that dumps 
 its render tree but does not do pixel testing.

Yes, it might make sense to do this (although it's not obvious to me
how we would do this without modifying the test sources). Maybe we
would need to maintain a separate manifest or some other list
somewhere to indicate which dirs or tests should include pixel
results.

 I think there is a high value to importing standards test suites wholesale, 
 even if they overlap with our existing coverage. Picking and choosing subsets 
 makes things  more complicated. If there are significant externalities to 
 adding particular kinds of tests, I would prefer we mitigate those 
 externalities rather than run fewer tests.

I'm not a fan of importing subsets of tests :).

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Maciej Stachowiak

On May 23, 2012, at 3:13 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com 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 have any
 experience maintaining a non-pixel-test-running port.

There are occasional changes that require rebaselining a very large number of 
render tree dumps. In my experience, this happens much less often than the 
frequency at which Chromium ports update pixel results, by several orders of 
magnitude.

 
 We can address the pixel result issue by introducing a new test that dumps 
 its render tree but does not do pixel testing.
 
 Yes, it might make sense to do this (although it's not obvious to me
 how we would do this without modifying the test sources). Maybe we
 would need to maintain a separate manifest or some other list
 somewhere to indicate which dirs or tests should include pixel
 results.

The quick and dirty way would be to add a SkipPixel directive (or whatever) to 
TestExpectations.

Cheers,
Maciej

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


Re: [webkit-dev] Importing W3C tests to webkit

2012-05-23 Thread Dirk Pranke
On Wed, May 23, 2012 at 2:59 PM, Jacob Goldstein jac...@adobe.com 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 for review (and doing this going forward, e.g. no
 longer requiring approval upon submission).

 Apparently, not enough people are reviewing tests, and as a result, tests
 can linger for months (or longer) before ever being looked at.  Once
 browser vendors start implementing features, associated tests will be
 revisited for that area.

 This has by no means been decided, but something we should consider if it
 ultimately does come to fruition.  If W3C tests are no longer
 reviewed, this would mean importing tests without any knowledge of their
 accuracy - though that will still allow us to catch regressions.

Ick :(. I suppose if the test suites are mostly coming from
established browser vendors or other trusted sources (who have been
running them on their own browsers for a while) this isn't so bad, but
it would be nice to see the suites get vetted somehow prior to them
getting blessed by the w3c. Levels of approval, or something?

 Dirk, I've updated the process on the Wiki page with the feedback you
 provided.  I hope I captured it all - I included everything that appeared
 to have agreement between you and Ryosuke.  Feel free to modify it
 directly if I missed anything, or let me know and I can refine it further.

It looks much closer to what I'd like, thanks! I'll probably modify it
a bit and/or send you some suggestions offlist for some minor things.

The one major issue I still have that I wouldn't want to just
add/sneak into the wiki, is that I still don't see much of a
discussion for how we identify duplicate tests.

The mindset I would prefer would be that, for a given test suite, the
person or persons importing the test suite should have to start by
identifying which existing tests we have for similar functionality,
and produce lists of which existing tests look like they are
duplicates and should be remvoed, which tests we have that should be
submitted back to the w3c for future inclusion, and which tests are
clearly webkit-specific and should be kept but identified as clearly
webkit-specific.

For example, if we import a flexbox test suite from css3, we should
default to removing fast/flexbox (and possibly also
ietestcenter/css3/flexbox).

[ This is a purely hypothetical example (I know nothing about these
test suites). I wish to re-emphasize that we will have to look at
these things on a case-by-case basis. ]

I have no idea how much work we'd be asking the importer to undertake,
but that's kinda the point. If we don't ask the importer to de-dup
things, who is realistically going to de-dup them later?

What do others thinks, is this too much to ask? If it is, how do we
avoid incurring further test debt over time?

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