Re: [webkit-dev] Does anyone still use the TestFailures app?
On Mon, Nov 5, 2012 at 10:21 PM, Dirk Pranke dpra...@chromium.org wrote: http://build.webkit.org/TestFailures/ I think Adam Roben was working on this a year or so ago. It appears to be broken at the moment (it's likely that I broke it, in fact), but before I spend much time fixing it I thought I'd check. I've never actually used it myself, so I'm not sure what all it was supposed to do; it looks like it overlaps in functionality some with the flakiness dashboard, but was probably written before the flakiness dashboard worked with the build.webkit.org bots and everyone was converted to using NRWT. If anyone is still using it (or would if it was actually working) in preference to the flakiness dashboard, can you let me know why? Ideally I'd like to get rid of it and roll any good features it had into the flakiness dashboard, but I'm happy to fix it and/or keep it around if it does other things I'm not aware of or if people are still using it. Cheers, -- Dirk I use it a lot. First stop when it is my gardening day. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Chromium for Android upstreaming has been completed!
Hi WebKit! Following Adam’s progress update on the Chromium-Android port in July[1], we’re happy to tell you that our upstreaming has been completed and that the Chromium-Android port is now fully supported. We’ve closed the master bug: https://bugs.webkit.org/show_bug.cgi?id=66687 To give you a quick summary: * Chromium for Android builds upon the existing Chromium architecture, code and port. * Build bots are available on the WebKit waterfall, with layout tests being run on actual devices. * There are EWS bots building all patches as they’re being uploaded to Bugzilla. Of course there are more loose ends to address, but we expect to finish these not too long from now. Most notably, a Performance bot will be added to the WebKit waterfall and all tools, including garden-o-matic, will be brought up to speed for Android. Once again, huge thanks to the WebKit community for being supportive and helping us out not just on upstreaming, but also in development of features such as Text Autosizing[2]. Cheers, Peter and Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021516.html [2] https://bugs.webkit.org/show_bug.cgi?id=84186 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Chromium for Android upstreaming has been completed!
Nothing but awesome work, guys! Congrats. On Tue, Nov 6, 2012 at 1:56 PM, Peter Beverloo pe...@chromium.org wrote: Hi WebKit! Following Adam’s progress update on the Chromium-Android port in July[1], we’re happy to tell you that our upstreaming has been completed and that the Chromium-Android port is now fully supported. We’ve closed the master bug: https://bugs.webkit.org/show_bug.cgi?id=66687 To give you a quick summary: * Chromium for Android builds upon the existing Chromium architecture, code and port. * Build bots are available on the WebKit waterfall, with layout tests being run on actual devices. * There are EWS bots building all patches as they’re being uploaded to Bugzilla. Of course there are more loose ends to address, but we expect to finish these not too long from now. Most notably, a Performance bot will be added to the WebKit waterfall and all tools, including garden-o-matic, will be brought up to speed for Android. Once again, huge thanks to the WebKit community for being supportive and helping us out not just on upstreaming, but also in development of features such as Text Autosizing[2]. Cheers, Peter and Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021516.html [2] https://bugs.webkit.org/show_bug.cgi?id=84186 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Chromium for Android upstreaming has been completed!
On Tue, Nov 6, 2012 at 9:56 AM, Peter Beverloo pe...@chromium.org wrote: Following Adam’s progress update on the Chromium-Android port in July[1], we’re happy to tell you that our upstreaming has been completed and that the Chromium-Android port is now fully supported. We’ve closed the master bug: https://bugs.webkit.org/show_bug.cgi?id=66687 Awesome news! Congratulations. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About text decoration wavy style implementation on Skia platform
On November 5, 2012 at 7:27 PM Bruno Abinader brunoabina...@gmail.com wrote:
2012/11/5 Nico Weber tha...@chromium.org [mailto:tha...@chromium.org]
The spelling underline on OS X is not a wavy line. If you end up
changing the skia code, please make sure the chromium/mac spelling
underline doesn't become a wavy line.
Nico
Interesting point. Said this, I'd say it is so far a matter of porting the
drawErrorUnderline() code from Cairo/Qt into Skia and use it instead of
modifying drawLineForDocumentMarker. For Qt/Cairo implementations, instead of
duplicating code, just make use of the already implemented function with
attention to use proper text decoration colors.
Hi,
The attached patch replaces drawErrorUnderline() call in
drawLineForDocumentMarker() with a call to drawLine() using wavy stroke. The
patch is small and the result is pretty the same (I can attach the screenshots
if you want to see it). Please take a look.
Lamarque V. Souza
Software Engineer (basyskom.com)
Nokia Certified Qt Specialistdiff --git a/Source/WebCore/platform/graphics/qt/GraphicsContextQt.cpp b/Source/WebCore/platform/graphics/qt/GraphicsContextQt.cpp
index 44bc0ed..dc83bf7 100644
--- a/Source/WebCore/platform/graphics/qt/GraphicsContextQt.cpp
+++ b/Source/WebCore/platform/graphics/qt/GraphicsContextQt.cpp
@@ -992,6 +992,7 @@ void GraphicsContext::drawLineForText(const FloatPoint origin, float width, boo
}
+#if !ENABLE(CSS3_TEXT)
/*
* NOTE: This code is completely based upon the one from
* Source/WebCore/platform/graphics/cairo/DrawErrorUnderline.{h|cpp}
@@ -1068,6 +1069,7 @@ static void drawErrorUnderline(QPainter *painter, qreal x, qreal y, qreal width,
painter-drawPath(path);
}
+#endif // CSS3_TEXT
void GraphicsContext::drawLineForDocumentMarker(const FloatPoint origin, float width, DocumentMarkerLineStyle style)
@@ -1089,7 +1091,17 @@ void GraphicsContext::drawLineForDocumentMarker(const FloatPoint origin, float
return;
}
+#if ENABLE(CSS3_TEXT)
+StrokeStyle oldStrokeStyle = strokeStyle();
+setStrokeStyle(WavyStroke);
+float oldStrokeThickness = strokeThickness();
+setStrokeThickness(cMisspellingLineThickness);
+drawLine(IntPoint(origin.x(), origin.y() + cMisspellingLineThickness / 2), IntPoint(origin.x() + width, origin.y() + cMisspellingLineThickness / 2));
+setStrokeStyle(oldStrokeStyle);
+setStrokeThickness(oldStrokeThickness);
+#else
drawErrorUnderline(painter, origin.x(), origin.y(), width, cMisspellingLineThickness);
+#endif // CSS3_TEXT
painter-setPen(originalPen);
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: fixing indentation in JSC
All, Over the next week or so I plan to fix indentation in JavaScriptCore. Currently there is a tendency to indent four spaces inside namespaces, which is contrary to our style guide as I understand it. I will do this one file at a time. So far JSObject.h, JSArray.h, and JSCell.h are done. - If you want to help, then please do! - If you are cooking a big JSC patch and would like me to hold off on some files so that you don't have a massive conflict, let me know. This style change is not urgent. -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making more use of ScriptWrappable
On Nov 5, 2012, at 5:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak m...@apple.com wrote:
Sounds like a good idea. Three additional thoughts:
(1) It would be best to choose the objects to apply this to in some
data-driven way.
Do you have a suggestion for what data to use? As far as I can tell,
adding ScriptWrappable as a base class is a win whenever at least half
of the instances of the object have JavaScript wrappers (in the main
world):
It's clearly an all-round win for speed and memory when this condition is true.
I imagined some straightforward instrumentation to find classes where this
condition is true (or nearly true) on some representative set of websites.
Applying ScriptWrappable to these classes is definitely pure win.
When the condition is not true (wrapper exists in main world significantly less
than half the time), it's a size-speed tradeoff. It may be worth it in cases if
the memory cost is low and the speed gain is high (for example, one object per
document, but its wrapper is accessed often). That may require some judgment
calls.
(3) I suspect that we can handle this without adding an IDL attribute at
all. C++ overloaded functions could let the bindings do something different
for objects that inherit ScriptWrappable from ones that do not in a generic
way, without having to explicitly tell the bindings layer about the ways to
do it. Consider the ways unwrap() and toJS() are done. We don't have to say
anything special in the IDL or have any interface-specific knowledge in the
bindings, C++ overloading takes care of it.
Thanks for the suggestion. I got this work (at least for the V8
bindings---JSC is next on my list). To make something
ScriptWrappable, you just need to add ScriptWrappable as a base class:
-class DOMImplementation {
+class DOMImplementation : public ScriptWrappable {
I'm not super excited about the name given that all DOM objects are
wrappable by script. If folks have thoughts about a better name, I'd
appreciate suggestions.
I agree with you that the name could use improvement. The only suggestion I can
think of that is not ridiculously verbose would be InlineWrappable, but I am
not sure if that is more clear overall.
Cheers,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Stream API
Has anyone reviewed the Stream API proposal from Microsoft? Here's the spec: http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm I see only a little mention of it on webapps-public: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html (I haven't looked over the proceedings from TPAC.) Thoughts on this API? My take: It seems useful to have a variant of Blob that supports data of unknown length. It seems a bit unfortunate to have StreamReader and FileReader, which are so similar. StreamBuilder seems like it may be unnecessary given that it does not support appending Streams. It seems like providing a way to get a Stream from a Blob would be sufficient, or if we could just pass Blobs to any API that takes a Stream, then we wouldn't need StreamBuilder. That is, Blobs should really just be Streams of known length. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] The --test-list option behavior in NRWT
Hi WebKitties, I'd like to see in what scale the --test-list option in NRWT is used and whether anyone would object a change in how its usage behaves. Currently the test gathering takes into account any paths that were passed in through the command line and any paths listed in the file to which a possible --test-file option points[1]. These paths are then expanded if necessary (due to platform-specific tests and virtual test suites) and all the tests to which these paths apply are gathered[2]. All the gathered tests are then either sorted into a natural order or randomized (if the --randomize-order option is used)[3]. I'd like to propose a change in the behavior when using the --test-list option. When used, the tests would be gathered only from the paths listed in the file to which the option points. Also, the gathered tests would be sorted to follow the order of the paths in the test list file. For instance, consider the following two entries being placed in the test list file: c/d/e.html a/b/ The current behavior would gather all the tests to which these two paths apply and sort them in this order (on the premise that no other paths are passed through the command line arguments): a/b/1.html a/b/2.html c/d/e.html The new behavior would place the c/d/e.html test at the top of the list but sort the other two tests in order, like this: c/d/e.html a/b/1.html a/b/2.html The idea behind this is to be able to specify the exact order in which the tests should be run. I'm currently playing around with a tool that randomly chooses a certain number of tests, runs them and bisects down the first regression that occurs (if any) to the smallest possible ordered list of tests that reproduces that regression. The proposed change makes this a simple task from the test listing perspective and I'd argue that exact test ordering is the main point of an option such as --test-list. Currently I'm using an untested workaround of adding a new option that specifies the tests should be reordered back to the original order that the test list file provided, but I'd like to move on with implementing the change in behavior if everyone feels it's OK and won't tamper with his/her workflow. -Z [1] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_finder.py#L46 [2] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/base.py#L576 [3] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py#L309 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
