[webkit-dev] Guide: How to enable Form features

2013-02-13 Thread TAMURA, Kent

We made a wiki page to describe how to enable HTML5 form-related features:
http://trac.webkit.org/wiki/EnableFormFeatures

If you have questions, please ask me and Keishi Hattori.


--
TAMURA Kent
Software Engineer, Google



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


Re: [webkit-dev] Is the wxWidgets port maintained?

2013-02-13 Thread Simon Hausmann
On Tuesday, February 12, 2013 03:07:33 AM Dirk Pranke wrote:
 On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org 
wrote:
  I am sorry, I should have given more context.
  
  There is visibly a growing discontent in the community about the cost
  imposed from small ports. Just two weeks ago, there were 2 threads
  discussing the cost of peripheral ports.
  I am convinced a part of this is technical. The project has not changed
  its
  policies while the number of ports was growing. While duplicated code and
  interfaces was okay when there were only 3 ports, it has become a pain
  when
  we have 7+ ports to updates ...
  In his email WebKit Wishes, Eric said It can’t be the job of the core
  maintainers to care about all the peripheral ports which contribute very
  little core code.
 
 I think it was an entirely reasonable question to ask if the wx port
 was being maintained, but I'm surprised by how this thread has
 evolved.
 
 There is a lot of discussion going on about the cost of so many ports,
 but not much about the benefits.

Indeed. For example the small ports have successfully attracted people in the 
past to join the project. Those people built skills and gained visibility in 
in trunk, certainly helping them to get hired later by other bigger companies 
to continue to work on WebKit.

 Speaking personally, even before I joined Google, I was drawn to
 WebKit partially because it was used on such a wide variety of
 projects and in so many different ways. I was fortunate to be able to
 get a job that allows me to contribute to it, and I have found the
 work that I've done to help maintain the peripheral ports, while not
 pain free, quite rewarding (although I would be quite happy if it was
 less costly, of course).
 
 My point is that I think that lots of ports are part of what makes
 WebKit the goodness it is. Maybe I'm alone here, or at best part of a
 minority, but I wanted us to not lose sight of this idea.

It's indeed an expressed goal of the project to be portable and to provide 
infrastructure. Also quoting from the project goals: In addition, we strive 
to create a courteous, welcoming environment that feels approachable to 
newcomers.


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


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Shezan Baig
Welcome!

I'm very interested in following the multicolumn changes you submitted - in
particular the changes for page floats and column spans, but I couldn't
find the relevant bugs,  Do you happen to have links for those?

Thanks, -shez-



On Wed, Feb 13, 2013 at 3:06 AM, Håkon Wium Lie howc...@opera.com wrote:

 Dear WebKit community,

 Many of us have met through various web standards efforts, such as
 W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
 forum for us: the webkit-dev mailing list.

 We have known WebKit and its KTHML predecessor for some time. Lars
 Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
 years. TrollTech and Opera shared a building in Oslo, a building which
 has earned its place in the rendering engine hall of fame.

 Some of our best programmers have been working on the WebKit code for
 a while, and today we have announced that we will be using the WebKit
 engine in the future [1]. We will also submit our code; switching from
 Presto to WebKit frees up resources and allows us to contribute to the
 WebKit platform.

 The first contributions from our side will be in multi-column layout
 [2]. We have experimented with combining multicol layout with
 page floats and column spans [3]; in 10 lines of CSS code one can
 create amazingly beautiful, scaleable and responsive paged
 presentations [4].

 We hope to work with you to further strengthen the open web that we
 all believe in.

[1] http://www.opera.com/press/releases/2013/02/13/
[2] http://www.w3.org/TR/css3-multicol/
[3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
[4] http://people.opera.com/howcome/2013/02-reader

 Cheers,

 Håkon Wium Lie
 CTO Opera Software
 http://people.opera.com/howcome
 ___
 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] Opera and WebKit

2013-02-13 Thread Morten Stenshorne
Hello Shezan,

Shezan Baig shezbaig...@gmail.com writes:

 I'm very interested in following the multicolumn changes you submitted - in
 particular the changes for page floats and column spans, but I couldn't find
 the relevant bugs,  Do you happen to have links for those?

For now we will only submit some general and rather minor multicol
layout improvements. Support for page floats and multicol nesting isn't
ready yet, and we'd also better discuss it with the code owners before
submitting anything as substantial as that.

-- 
 Morten Stenshorne, developer, Opera Software ASA 
 Office: +47 23692400 -- Mobile: +47 93440112 
-- http://www.opera.com/ -
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Ryosuke Niwa
Welcome to the WebKit community.

On Wed, Feb 13, 2013 at 6:19 AM, Morten Stenshorne msten...@opera.comwrote:

 Hello Shezan,

 Shezan Baig shezbaig...@gmail.com writes:

  I'm very interested in following the multicolumn changes you submitted -
 in
  particular the changes for page floats and column spans, but I couldn't
 find
  the relevant bugs,  Do you happen to have links for those?

 For now we will only submit some general and rather minor multicol
 layout improvements. Support for page floats and multicol nesting isn't
 ready yet, and we'd also better discuss it with the code owners before
 submitting anything as substantial as that.


FYI, there are no code owners in WebCore although reviewers tend to have
areas of expertise. In fact, we often upload work-in-progress patches on
the Bugzilla to discuss and make design decisions.

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


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Håkon Wium Lie
Morten Stenshorne wrote:

  Shezan Baig shezbaig...@gmail.com writes:
  
   I'm very interested in following the multicolumn changes you submitted - in
   particular the changes for page floats and column spans, but I couldn't 
   find
   the relevant bugs,  Do you happen to have links for those?
  
  For now we will only submit some general and rather minor multicol
  layout improvements. Support for page floats and multicol nesting isn't
  ready yet, and we'd also better discuss it with the code owners before
  submitting anything as substantial as that.

Indeed. HTML/CSS code examples for the more ambitious parts are
available from here, along with screenshots:

  http://people.opera.com/howcome/2013/02-reader/

We hope there is interest in the WebKit commmunity to add solid
support for multicol layout along with paged mode, colum spans, and
page floats. The syntax is minimal, the visual effects are stunning. 

Cheers,

-hkon
  Håkon Wium Lie  CTO °þe®ª
howc...@opera.com  http://people.opera.com/howcome
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Dimitri Glazkov
Welcome, Opera folks! Exciting stuff.

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


Re: [webkit-dev] Exposing Mouse Simulation event API from webkit

2013-02-13 Thread Julien Chaffraix
webkit-dev is reserved for discussion about WebKit development. Your
question seems to be about some changes you want to do locally so it
belongs to webkit-help
(https://lists.webkit.org/mailman/listinfo/webkit-help).

 I have done changes to expose the mouse simulation API from webkit.
 Everything is working fine. But I have a issue I have done changes in
 webpage.message.in file .

There is no such file in WebKit:

find . -name *.in|grep webpage

If you are adding new files, it's difficult for anyone to know what
you did and you are more or less on your own. If you really want some
help, please send a lot more details to webkit-help about what you are
doing if you want to get some good quality answer.

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


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Dirk Schulze
I interprete 'Chromium' as V8 and not JSC.

Dirk

2013/2/13 Oliver Hunt oli...@apple.com

 Welcome to webkit!

 Are you still going to be using Carakan?  Or are you planning on using
 WebKit's ES engine?  If so are there any Carakan-JSC compatibility issues
 we should be aware of?

 --Oliver

 On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie howc...@opera.com wrote:

  Dear WebKit community,
 
  Many of us have met through various web standards efforts, such as
  W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
  forum for us: the webkit-dev mailing list.
 
  We have known WebKit and its KTHML predecessor for some time. Lars
  Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
  years. TrollTech and Opera shared a building in Oslo, a building which
  has earned its place in the rendering engine hall of fame.
 
  Some of our best programmers have been working on the WebKit code for
  a while, and today we have announced that we will be using the WebKit
  engine in the future [1]. We will also submit our code; switching from
  Presto to WebKit frees up resources and allows us to contribute to the
  WebKit platform.
 
  The first contributions from our side will be in multi-column layout
  [2]. We have experimented with combining multicol layout with
  page floats and column spans [3]; in 10 lines of CSS code one can
  create amazingly beautiful, scaleable and responsive paged
  presentations [4].
 
  We hope to work with you to further strengthen the open web that we
  all believe in.
 
[1] http://www.opera.com/press/releases/2013/02/13/
[2] http://www.w3.org/TR/css3-multicol/
[3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
[4] http://people.opera.com/howcome/2013/02-reader
 
  Cheers,
 
  Håkon Wium Lie
  CTO Opera Software
  http://people.opera.com/howcome
  ___
  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] Opera and WebKit

2013-02-13 Thread Michelangelo De Simone
Hi there,

it's great to have you in the community, welcome!

A question, that it's likely to be OT for this list [1]: do you guys have any 
plan to open Presto's source?

[1] …but given the magnitude of this, I guess I'll be indulged.:)
-- 
Bye,
Michelangelo

Il giorno Feb 13, 2013, alle ore 12:06 AM, Håkon Wium Lie howc...@opera.com 
ha scritto:

 Dear WebKit community,
 
 Many of us have met through various web standards efforts, such as
 W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
 forum for us: the webkit-dev mailing list.
 
 We have known WebKit and its KTHML predecessor for some time. Lars
 Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
 years. TrollTech and Opera shared a building in Oslo, a building which
 has earned its place in the rendering engine hall of fame.
 
 Some of our best programmers have been working on the WebKit code for
 a while, and today we have announced that we will be using the WebKit
 engine in the future [1]. We will also submit our code; switching from
 Presto to WebKit frees up resources and allows us to contribute to the
 WebKit platform.
 
 The first contributions from our side will be in multi-column layout
 [2]. We have experimented with combining multicol layout with
 page floats and column spans [3]; in 10 lines of CSS code one can
 create amazingly beautiful, scaleable and responsive paged
 presentations [4].
 
 We hope to work with you to further strengthen the open web that we
 all believe in.
 
   [1] http://www.opera.com/press/releases/2013/02/13/
   [2] http://www.w3.org/TR/css3-multicol/
   [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
   [4] http://people.opera.com/howcome/2013/02-reader
 
 Cheers,
 
 Håkon Wium Lie
 CTO Opera Software
 http://people.opera.com/howcome
 ___
 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] Opera and WebKit

2013-02-13 Thread Håkon Wium Lie
Michelangelo De Simone wrote:

  it's great to have you in the community, welcome!
  
  A question, that it's likely to be OT for this list [1]: do you
  guys have any plan to open Presto's source?

It may be that the Presto code will be released, but for now it's all
hands on deck making the transition. So far, it looks good :)

Cheers,

-hkon
  Håkon Wium Lie  CTO °þe®ª
howc...@opera.com  http://people.opera.com/howcome
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Opera and WebKit

2013-02-13 Thread Maciej Stachowiak

Welcome to the WebKit community! Opera has a long and impressive history of 
pushing the Web platform forward. I look forward to working together to advance 
the Web; I think it's a great opportunity for all of us.

Regards,
Maciej

On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie howc...@opera.com wrote:

 Dear WebKit community,
 
 Many of us have met through various web standards efforts, such as
 W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
 forum for us: the webkit-dev mailing list.
 
 We have known WebKit and its KTHML predecessor for some time. Lars
 Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
 years. TrollTech and Opera shared a building in Oslo, a building which
 has earned its place in the rendering engine hall of fame.
 
 Some of our best programmers have been working on the WebKit code for
 a while, and today we have announced that we will be using the WebKit
 engine in the future [1]. We will also submit our code; switching from
 Presto to WebKit frees up resources and allows us to contribute to the
 WebKit platform.
 
 The first contributions from our side will be in multi-column layout
 [2]. We have experimented with combining multicol layout with
 page floats and column spans [3]; in 10 lines of CSS code one can
 create amazingly beautiful, scaleable and responsive paged
 presentations [4].
 
 We hope to work with you to further strengthen the open web that we
 all believe in.
 
   [1] http://www.opera.com/press/releases/2013/02/13/
   [2] http://www.w3.org/TR/css3-multicol/
   [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
   [4] http://people.opera.com/howcome/2013/02-reader
 
 Cheers,
 
 Håkon Wium Lie
 CTO Opera Software
 http://people.opera.com/howcome
 ___
 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] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread Dongsung Huang
I like this idea. I cannot find any harm if we have this functionality.
When a pixel test is more succinct, we can make a pixel test. When a
'getPixel on Javascript' test is more succinct, we can make a 'getPixel'
test.
As
http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree
said
'Pixel tests are a burden on every ports as any small change in the engine
could lead to your test needing a new pixel result.', new test
functionality that can be an alternative of pixel test is good!
philip canvas tests (LayoutTests/canvas/philip) has no pixel test because
of the power of getImageData API in canvas spec.

I can put two examples for the power of functionality that Noam suggested,

Case 1: CSS Filters  Shaders
I wanted this test functionality when I commented
http://webkit.org/b/97859#c19
If I want to make gaussian blur test, I prefer using 'getPixel' test as
follows,

ASSERT(getPixel(10, 10) = rgba(255, 0, 0, 255));
ASSERT(getPixel(10, 15)  rgba(255, 0, 0, 98)  getPixel(10, 15) 
rgba(255, 0, 0, 102));

If we don't have 'getPixel', we need to capture all port's image results
because all port's painting engine would make a bit different result. As
you know, it is painful.


Case 2: Fixed Position Element
I guess it is one of reasons why Noam suggested.
Currently, Qt and EFL AC (a.k.a Coordinated Graphics) has a problem related
to fixed position element.
During panning animation, Fixed position element is slightly flickering.

If we have 'getPixel', we can make a succinct test case.

PRECONDITION : a green fixed position div is on the white body. The rect of
the div is rect(10, 10, 30, 30).
function repeatedlyCalledDuringScrolling() {
ASSERT(getPixel(15, 9) == white);
ASSERT(getPixel(15, 10) == green);
ASSERT(getPixel(9, 15) == white);
ASSERT(getPixel(10, 15) == green);

}

WDYT?

Best regards,

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


Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread Benjamin Poulain
On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang luxte...@company100.netwrote:

 I like this idea. I cannot find any harm if we have this functionality.


Those changes are not harmless. There are people monitoring tests results
full time in order to keep WebKit in good shape. No other part of WebKit
require continuous attention.


 Case 1: CSS Filters  Shaders
 I wanted this test functionality when I commented
 http://webkit.org/b/97859#c19
 If I want to make gaussian blur test, I prefer using 'getPixel' test as
 follows,


Why wasn't a ref-test a better solution in this particular case?

Case 2: Fixed Position Element
 [...]
 function repeatedlyCalledDuringScrolling() {
 ASSERT(getPixel(15, 9) == white);
 ASSERT(getPixel(15, 10) == green);
 ASSERT(getPixel(9, 15) == white);
 ASSERT(getPixel(10, 15) == green);
 
 }


I think this shows what I said about correctness and readability:
-Asserting the correctness of the test and the result becomes close to
impossible for the reader. One has to review the full code to have a chance
of understanding an error.
-You cannot cover non trivial cases (images, text, form elements, etc).
-And it is inefficient. You have to render each frame on the UIProcess,
move it to the WebProcess, and box it for JavaScript to process (with pixel
format conversions depending on your graphics system)

Of the ideas raised, I think this is one of my least favorite for testing
fixed positioning.

Benjamin
___
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

2013-02-13 Thread Christophe Dumez - SISA
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=188263action=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


Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread noam . rosenthal


From: ext Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org
Date: Thursday, February 14, 2013 8:07 AM
To: Dongsung Huang luxte...@company100.netmailto:luxte...@company100.net
Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org 
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction 
pixel-results on the fly

On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang 
luxte...@company100.netmailto:luxte...@company100.net wrote:
I like this idea. I cannot find any harm if we have this functionality.

Those changes are not harmless. There are people monitoring tests results full 
time in order to keep WebKit in good shape. No other part of WebKit require 
continuous attention.

Case 1: CSS Filters  Shaders
I wanted this test functionality when I commented http://webkit.org/b/97859#c19
If I want to make gaussian blur test, I prefer using 'getPixel' test as follows,

Why wasn't a ref-test a better solution in this particular case?
Because gaussian blurs on the GPU are not accurate, and look slightly different 
on different GPUs, but usually close enough.
We need a way to measure close enough for features where all you can get is 
close enough! Ref-tests and pixel-tests are way to rigid for that, and 
require constant rebaselines and headaches.


Case 2: Fixed Position Element
[...]
function repeatedlyCalledDuringScrolling() {
ASSERT(getPixel(15, 9) == white);
ASSERT(getPixel(15, 10) == green);
ASSERT(getPixel(9, 15) == white);
ASSERT(getPixel(10, 15) == green);

}

I think this shows what I said about correctness and readability:
-Asserting the correctness of the test and the result becomes close to 
impossible for the reader. One has to review the full code to have a chance of 
understanding an error.
We can generate PNGs when a snapshot is requested so that the tester can 
eyeball the results.

-You cannot cover non trivial cases (images, text, form elements, etc).
-And it is inefficient. You have to render each frame on the UIProcess, move it 
to the WebProcess, and box it for JavaScript to process (with pixel format 
conversions depending on your graphics system)
Another option is to do expose a partial comparison mechanism that runs in  the 
UI process.
E.g.
var snapshotHandle = testRunner.createSnapshot();
testRunner.comparePixel(snapshotHandle, 15, 20, 'white', { tolerance: 0.2 });

This way we can generate a visual representation of failures.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread Benjamin Poulain
On Wed, Feb 13, 2013 at 11:16 PM, Dirk Pranke dpra...@chromium.org wrote:

  Those changes are not harmless. There are people monitoring tests results
  full time in order to keep WebKit in good shape. No other part of WebKit
  require continuous attention.

 I'm sorry, but either I don't understand Dongsung's suggestion, or I
 don't understand your criticism. What does this sentence paragraph
 mean? Are you suggesting someone needs to look at this type of test
 full time in a way that we don't have to look at the other tests?


My lack of sleep is likely to blame here :)

All I am saying is tests have a hight cost when they start failing, we
should be careful how we design them so we can easily triage bad tests,
flaky tests, and real errors.


 Case 1: CSS Filters  Shaders
  I wanted this test functionality when I commented
  http://webkit.org/b/97859#c19
  If I want to make gaussian blur test, I prefer using 'getPixel' test as
  follows,
 
 
  Why wasn't a ref-test a better solution in this particular case?
 

 I'm curious, what would you imagine the ref test contains?


If I am not mistaken, the composition operations are parallel with the ones
of SVG and Canvas (aren't they?).
I would have attempted comparing the 3 implementations as it seems to me
the pixels values should be the same.

That was a genuine question about that case :)



  Case 2: Fixed Position Element
  [...]
  function repeatedlyCalledDuringScrolling() {
  ASSERT(getPixel(15, 9) == white);
  ASSERT(getPixel(15, 10) == green);
  ASSERT(getPixel(9, 15) == white);
  ASSERT(getPixel(10, 15) == green);
  
  }
 
 
  I think this shows what I said about correctness and readability:
  -Asserting the correctness of the test and the result becomes close to
  impossible for the reader. One has to review the full code to have a
 chance
  of understanding an error.
  -You cannot cover non trivial cases (images, text, form elements, etc).
  -And it is inefficient. You have to render each frame on the UIProcess,
 move
  it to the WebProcess, and box it for JavaScript to process (with pixel
  format conversions depending on your graphics system)
 
  Of the ideas raised, I think this is one of my least favorite for testing
  fixed positioning.
 

 Isn't his suggestion the equivalent of what we do today in text-only
 tests? i.e., printing pass or fail and making you have to look at
 the test itself to see what's being tested?

 If the correctness of the rendering depends on those 4 specific pixels
 having those four specific values, how exactly are you going to verify
 that by looking at it?

 Again, I think I'm just not understanding you here?


When looking at a test test, you follow the flow to know what it is
supposed to do and where it breaks.

How are you supposed to know, _by reading the code_, that the color at
position 15, 9 should be white?

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


Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread Benjamin Poulain
On Wed, Feb 13, 2013 at 11:27 PM, noam.rosent...@nokia.com wrote:

  Why wasn't a ref-test a better solution in this particular case?

  Because gaussian blurs on the GPU are not accurate, and look slightly
 different on different GPUs, but usually close enough.
 We need a way to measure close enough for features where all you can get
 is close enough! Ref-tests and pixel-tests are way to rigid for that, and
 require constant rebaselines and headaches.


There is _NO_ gaussian blur in that patch.

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


Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly

2013-02-13 Thread noam . rosenthal


From: ext Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org
Date: Thursday, February 14, 2013 8:36 AM
To: Noam Rosenthal noam.rosent...@nokia.commailto:noam.rosent...@nokia.com
Cc: luxte...@company100.netmailto:luxte...@company100.net 
luxte...@company100.netmailto:luxte...@company100.net, 
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org 
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction 
pixel-results on the fly

On Wed, Feb 13, 2013 at 11:27 PM, 
noam.rosent...@nokia.commailto:noam.rosent...@nokia.com wrote:
Why wasn't a ref-test a better solution in this particular case?
Because gaussian blurs on the GPU are not accurate, and look slightly different 
on different GPUs, but usually close enough.
We need a way to measure close enough for features where all you can get is 
close enough! Ref-tests and pixel-tests are way to rigid for that, and 
require constant rebaselines and headaches.

There is _NO_ gaussian blur in that patch.
DongSung mentioned gaussian blur in the comment, which is what I was referring 
to.
But other bugs as well, like delegated scrolling, also have that problem of 
results not being 100% the same every time.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev