Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
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 :)
Thank you for feedback! :)
I presented gaussian blur case to express my opinion effectively.
As I know, Adobe want to draw CSS Filters and SVG Filters using the same
code. And Canvas does not have something like Filters.
What I want to say is that there are some cases in which snapshot
functionality is more useful.
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
I agree on Dirk's opinion. I supports 3 points as follows:
1. we can help to understand what's goal of test by comments
2. when we want to see the graphical result, we can use MiniBrowser like
other text based test.
3. philip's canvas tests (http://philip.html5.org/tests/canvas/suite/tests/)
already use well getImageData to test.
I agree that snapshot test can make hardly maintainable tests, but we have
review process and we can make succinct tests like philip canvas test.
And when pixel test is more suitable, we can use pixel test also.
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
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] Changes to the WebKit2 development process
2013/1/10 Sam Weinig wei...@apple.com At this point, we ask that all completely non-trivial patches be reviewed by an owner, even if in port specific code. - Sam Hi Sam and webkit developers. I really appreciate WK2 owners' effort to improve all port specific code as well as WK2 code. However, recently EFL, Gtk and Qt (by Alphabetical order) developers are having a hard time due to decreasing productivity. For example, I had filed a platform specific patch and had it reviewed by a Qt reviewer 10 days ago. And then WK2 owner's review was needed to commit. One of the WK2 owners made an effort to review. However, compared to before, review speed dramatically decreased and I had to wait his response for several days. I understand the WK2 owner had many jobs besides reviewing this platform specific patch, and I really appreciated his effort and comment. Finally I had to separate the patch to a WebCore platform specific part and a WK2 platform specific part because many other bugs were blocked by the WebCore part. IMHO, recently, contributors as well as WK2 owners are a bit suffering from it. I think we can go to a better direction: making all developers happy as well as resolving WK2 owners' concerns. Cheers, Dongsung Huang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
