On Apr 16, 2012, at 4:30 PM, Maciej Stachowiak wrote:
On Apr 16, 2012, at 4:03 PM, Dirk Schulze wrote:
Different developers will have different priorities. HD image data and
async readback both have potential benefits in image quality and
nonblocking responsiveness respectively. Here
On Feb 29, 2012, at 9:44 AM, Simon Fraser wrote:
On Feb 29, 2012, at 9:32 AM, Hans Muller wrote:
Are the -webkit-transform-origin-x,y CSS properties on their way in our
out? The ugly little test below demonstrates that they're probably not
supported by Opera or Mozilla.
They are not
On Feb 21, 2012, at 10:13 AM, Levi Weintraub wrote:
Hi Dirk,
Inline:
On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
Hi Emil and Levi,
I have a question to sub pixels from the SVG point of view.
Right now a lot of content on renderers
Hi Emil and Levi,
I have a question to sub pixels from the SVG point of view.
Right now a lot of content on renderers and also in RenderStyle uses
LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would LayoutUnit
deal with SVG's float system? Your Wiki says that SVG's float system
Am 24.10.2011 um 21:51 schrieb Adam Barth:
I'd like to know what the actual threat of such timing attacks are. I've
seen claims of a maximum theoretical leak rate (in bits/s) but then counter
claims that since, in this case, it would be hard to distinguish the
difference in slowdown
I plan to use OpenCL to HW accelerate SVG and CSS Filters [1]. I'm targeting
OpenCL 1.1 which consists of two profiles: 'full' for the Desktop and
'embedded' for embedded devices like mobile phones. For filters I'll use
OpenCLs facilities for image processing from the 'full' profile. The most
Am 12.10.2011 um 00:24 schrieb Simon Fraser:
For this reason, I'd like to propose that on Mac, all pixel testing is done
using WebKit2, which you can get by passing -2 to run-webkit-tests or
new-run-webkit-tests. I can fix the scripts to print a warning if you pass
--pixel without -2 (or
Dean, do you want to reuse the existing filter code, or do you plan to write
another filter implementation just for CSS? Would be interesting if we would
need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent
of each other.
Like previous comments mention, Apple still
The color profile switches automatically for me on running pixel tests with
Lion or SL. How is it even possible that we got images with different color
profiles for mac results?
Dirk
Simon Fraser:
It turns out that some of the layout test expected.png files have color
profiles (Generic
We could at least remove the subsets of SVG. Some developers build without SVG
for compile time reasons.
Dirk
Am 09.09.2011 um 23:45 schrieb Levi Weintraub:
I know webOS ships (or doesn't these days?) sans-SVG.
On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote:
I am
Am 27.07.2011 um 23:03 schrieb Darin Fisher:
Perhaps related to this thread, shouldn't we be basing SVG animations off of
the same animation scheduler that drives requestAnimationFrame and soon CSS
animations (https://bugs.webkit.org/show_bug.cgi?id=64591)? It seems less
than ideal to
Am 29.06.2011 um 05:42 schrieb TAMURA, Kent:
I'm a little negative of developing a new XML parser. I'm afraid that the new
parser introduces a lot of security/stability problems which existing parsers
already resolved.
I feel the same. Writing a new parser from scratch means introducing a
If you use webkit-patch everything just magically works (yay!!)
--Oliver
I agree! And if people would use it on uploading patches to a bug report, we
wouldn't need a style-bot.
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Hi
I noticed that we have irregular nightly builds for Mac
(http://nightly.webkit.org/builds/trunk/mac/1). Between two builds is sometimes
more than a week. I'm tracking a bug that was introduced between 2010-12-17 and
2011-01-08. More than 1000 Patches were committed during that time. This
Reorganising the source tree like we've been doing recently means that the
build scripts for the nightlies have to be updated. A number of the places
where the updates were needed were very late in the build process, meaning
that a three hour turnaround per attempt at a fix was required.
At first SVGMatrix and the complete SVG code itself is not using
TransformationMatrix. We had bigger performance problems and the memory amount
raised up by 6-10%. Thats why we decided to turn back to AffineTransform.
Because of the platform dependencies of TransformationMatrix. I noted that
Am 05.01.2011 um 06:14 schrieb Maciej Stachowiak:
It might make sense to use subdirectories of rendering/, as svg has started
to (although this seems incomplete - SVG folks, is the plan to move the
remaining SVG-related rendering files from rendering/ to rendering/svg?).
Yes it is on the
Hi webkit-dev,
I was looking at the MathML code recently and I wonder, that all files are
located at WebCore/mathml, even the renderer. Shouldn't the rendering code be
moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?
Dirk
___
Does it support pixel test updates? Is it possible to extend this tool if not?
This would limit the maintenance cost and every commiter should rebaseline mac
if the change is a progression, or the difference is machine dependent
(but not OS dependent).
Dirk
Am 12.10.2010 um 22:49 schrieb Adam
We missed many changes because of an existent tolerance level in the past. We
made a baseline for MacOS Leopard as well as Snow Leopard and I would active
pixel tests just for those two bots. I don't expect any problems. Niko and I
run pixel tests on different machines and get the same results.
The problem I worry about is that on future Mac OS X releases, rendering of
shapes may change in some tiny way that is not visible but enough to cause
failures at tolerance 0. In the past, such false positives arose from time to
time, which is one reason we added pixel test tolerance in
I strongly support pixel tests for SVG on the bots! Niko and me are hard
working to get SVG pxiel perfect at all time. We run pixel tests on every patch
we apply to the SVG code. And it would really help us if the bots blame any
change that causes a pixel test to fail, or at least give some
The main reason is DumpRenderTree. If we use the Path::createEllipse
logic of the different platforms, we end up with different LayoutTest
results on SVG between platform, since we create them by traversing the
path data of the certain platform.
So changing this is painful and causes a lot of new
Am Sonntag, den 19.09.2010, 09:32 +0200 schrieb Dirk Schulze:
The main reason is DumpRenderTree.
Let me rephrase it: The only reason why we still use this logic is
DumpRenderTree.
If we use the Path::createEllipse
logic of the different platforms, we end up with different LayoutTest
results
Hi Yuzo,
the issue should be fixed in WebCore/rendering/RenderSVGPaintServer.
Removing this check in the test doesn't help to fix the bug :-)
Dirk
Am Montag, den 28.06.2010, 11:05 +0900 schrieb Yuzo Fujishima:
Hi,
Any update on this?
Is it OK to remove 'stroke=#0' from:
Hi Andrei,
this kind of question should be asked in a bug report. Bug 23526 is the
best location, since it is a general issue with clipToImageBuffer on the
Cairo ports.
I'm interessted in a test case, where the patch on the mentioned bug
report does not work. I don't know of an example, that
Hi,
Microsoft announced a new test suite, the Internet Explorer testing
center together with the first preview of the upcoming ie9.
http://samples.msdn.microsoft.com/ietestcenter/
In one table the current releases of the major browsers are compared
to ie9. Safari and Chrome do fail on more than
Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser:
It could be an image, or it could be a configuration of div elements, or a
table, or something else that can be configured to look exactly the same as
the CSS border property being tested.
Simon
I like the idea of reftests.
Would be great to have pixel tests on a bot back. And it would be great,
if the commit queue runs them too. Especially for patches of
non-commiters.
-Dirk
Am Donnerstag, den 07.01.2010, 10:19 -0800 schrieb Dimitri Glazkov:
Are we planning to run pixel tests on the build bots? What's the
We have somtimes constructs like
#endif // ENABLE(SVG)
#endif // Foo_h
It just helps to understand why there are two endif's and what they are
good for. I think it's not a style issue not to write this comment, but
it can be helpful.
-Dirk
Am Montag, den 04.01.2010, 15:41 -0800 schrieb Darin
What kinds of tests do we have for the code already? Do we have code that
tries to exercise edge cases? Do we have a fuzzer of some sort?
-- Darin
Every effect that was implemented has at least one test. They are mostly
simple test cases that just test one effect at once but there are
Hi,
I thougt that we already had a bug about this. It is a good idea to
support this feature in general. Even if our support for SVG 1.1 is not
perfect, we should think about some features of SVG 1.2 like media
support and also non scaling strokes. But implementing non scaling
strokes is not that
If you build the cairo version on either windows or linux, your cairo
library is older than 1.4.
cairo_clip_extents is added to cairo with version 1.4. This is fixed in
newer tarballs by checking your installed version of the cairo library.
Just use a newer tarball or update cairo.
Dirk
Am
101 - 133 of 133 matches
Mail list logo
