Unfortunately, even for SVG or images, different drawing
implementations will lead to different pixel results. Like this Skia
bug, http://code.google.com/p/skia/issues/detail?id=179 , which caused
most pages using SkFixed calculation, e.g. round-corner, gradient,
svg, etc., produce different
It looks like only the .idl files get pre-processed. The .in files have
comments that start with #, meaning that they cannot be pre-processed by
a C++ preprocessor. We need to change the comment styles for .in files to
//.
I've added https://bugs.webkit.org/show_bug.cgi?id=62114 to track the
Hi,
If you maintain some bots, and you saw rounding issues which makes 1px
difference on let's say 32 and 64 bit environments for several layout
tests, you may interested in this bug:
https://bugs.webkit.org/show_bug.cgi?id=62204
I try to explain what exactly happens there, and it could be used
Reftests?
-- Dirk
On Mon, Jun 6, 2011 at 11:00 PM, Hao Zheng zheng...@chromium.org wrote:
Unfortunately, even for SVG or images, different drawing
implementations will lead to different pixel results. Like this Skia
bug, http://code.google.com/p/skia/issues/detail?id=179 , which caused
most
On Tue, Jun 7, 2011 at 5:34 AM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:
If you maintain some bots, and you saw rounding issues which makes 1px
difference on let's say 32 and 64 bit environments for several layout
tests, you may interested in this bug:
On Tue, Jun 7, 2011 at 9:33 AM, Evan Martin e...@chromium.org wrote:
On Tue, Jun 7, 2011 at 5:34 AM, Zoltan Herczeg zherc...@inf.u-szeged.hu
wrote:
If you maintain some bots, and you saw rounding issues which makes 1px
difference on let's say 32 and 64 bit environments for several layout
It looks like only the .idl files get pre-processed. The .in files have
comments that start with #, meaning that they cannot be pre-processed by
a C++ preprocessor. We need to change the comment styles for .in files to
//.
That's partly right. Some .in files are preprocessed (tag and
Eric,
You're right that in flickr.com main page, Webkit spends very little time
in StyleForElement. However, if you visit
http://www.flickr.com/photos/tags/sanfrancisco/ , WebKit spends most of
its CSS time in StyleForElement. For example, in our test machine (an
8-core Intel Xeon, 2.8GHz)
You should start by filing a bug at bugs.webkit.org on that 66%. There may be
other easier optimizations that don't have all the complexity of threading.
Simon
On Jun 7, 2011, at 11:22 AM, Kulanthaivel Palanichamy wrote:
Eric,
You're right that in flickr.com main page, Webkit spends very
You noted it spends 66% of its CSS time in StyleForElement. What
about total page load time?
Then again 6450ms spent in CSS sounds like a lot of time regardless.
Answering what % of total page load time we're spending in CSS (or
StyleForElement) is important.
Loading
I'm not convinced focusing on single-threaded performance is the best
approach. Of course, I support any work done to improve it. Antti's work the
past few months has been awesome and I expect there is room for other
improvements.
However, many of the performance improvements we can make to the
On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler da...@apple.com wrote:
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
From the perspective of Node itself, I'm not sure why this would be a
big task. There shouldn't be any const accessors that return non-const
pointers. Simply removing the
For example:
fast/borders/borderRadiusArcs01.html
svg/W3C-SVG-1.1-SE/pservers-pattern-04-f.svg
fast/backgrounds/body-generated-image-propagated-to-root.html
Hundreds of tests with skia drawing are affected by this bug, e.g.
svg-tests, round-corner, gradient, etc.
On Tue, Jun 7, 2011 at 11:58
On Wed, Jun 8, 2011 at 7:54 AM, Ojan Vafai o...@chromium.org wrote:
However, many of the performance improvements we can make to the
single-threaded approach are limited in scope or have other trade-offs. For
example, if I understand https://bugs.webkit.org/show_bug.cgi?id=49876
correctly,
Is it woking for now?
I posted a patch which must fail on Chromium-linux, but the EWS didn't post
any errors.
https://bugs.webkit.org/show_bug.cgi?id=62196
On Tue, May 3, 2011 at 10:37, Adam Barth aba...@webkit.org wrote:
The result of the experiment is success! These are now running for
Why must it fail on Chromium Linux? We're not running pixel tests
yet, if that's what you're concerned about.
Adam
On Tue, Jun 7, 2011 at 9:49 PM, TAMURA, Kent tk...@chromium.org wrote:
Is it woking for now?
I posted a patch which must fail on Chromium-linux, but the EWS didn't post
any
* My patch updates the render tree dump of thumbslider-no-parent-slider.html
significantly.
* Chromium-linux has an old result,
platform/chromium-win/fast/forms/thumbslider-no-parent-slider-expected.txt.
(Chromium-linux searches chromium-win directory for fallback results.)
*
Very interesting. I'll investigate.
Adam
On Tue, Jun 7, 2011 at 10:21 PM, TAMURA, Kent tk...@chromium.org wrote:
* My patch updates the render tree dump of thumbslider-no-parent-slider.html
significantly.
* Chromium-linux has an old result,
18 matches
Mail list logo
