August 2010 - webkit-dev - lists.webkit.org

Name nitpick: "layout tests"
by Darin Adler 04 Aug '10

04 Aug '10

Hi folks. WebKit regression tests are in a directory named LayoutTests. The object the tests uses to do special test-specific operations is "layoutTestController". Both of these names are unwanted baggage, left over from when the test machinery was only good for testing layout. The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! The object should be named testController, or perhaps someone can think of an even better name. A super-short one would probably be OK; the only practical problem is that we don’t want to choose a name that is likely to conflict with something we’ll add to HTML5 in the future. (I would have used the phrase “the web platform” instead of HTML5, which would be way better for pedants, but I think it would confuse others.) While we may be stuck with the current names for some time, we should not introduce new uses of the word "layout" in the context of our regression test machinery. That’s why the script is named run-webkit-tests, not run-layout-tests. I renamed that one in time, before we went wide with the WebKit project. It’s my fault we didn’t rename those other things sooner. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. Your thoughts? -- Darin

8 9

Canvas performance and memory usage
by Christophe Public 03 Aug '10

03 Aug '10

Hi, There is a performance hit when using HTML canvas when using ImageBufferCairo: - As soon as something is rendered in the canvas, the HTMLCanvasElement::willDraw method is called which in turn calls clearImage on the imageBuffer if one is already present. - When the render tree is traversed (HTMLCanvasElement::paint gets called), the image containing the canvas is drawn using GraphicsContext::drawImage. Unfortunately, ImageBuffer::image() (in BufferImageCairo.cpp) allocates a new surface, and copies the image surface into it. When very frequent updates are done in the canvas, this double buffering causes significant performance degradation that worsens with large canvas sizes. In addition, the extra memory consumption can become quite expensive especially on embedded devices. Can anybody explain why this double buffering is necessary for ImageBuffer specifically for the Cairo port? We are looking at disabling the double buffering at least for the canvas because of both performance and memory issues. It would also be nice to disable it for images as well but we would like to understand why in the first place it was added. Note that a code comment states "This seems silly, but is the way the CG port works: image() is intended to be used only when rendering is complete." Any suggestion on how to fix this issue is welcome. If it is considered a bug, then I will create a bug as well to keep track of it. Regards, Christophe

2 1

Leopard Release Builder -- Slave Lost
by Eric Seidel 03 Aug '10

03 Aug '10

http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) We lost the slave over 3 days ago. :( (The tree is also generally on fire right now...) -eric

2 2

Rendering a PDF on an HTML5 Canvas using WebKit/AIR
by Andrew Sealy-Bell 03 Aug '10

03 Aug '10

Hi, I'd like to know if anybody has experience with rendering a PDF on an HTML5 canvas? I'd like to to this and listen for mouse events etc. do overlay some customised functionality on top. I'd like to be able to do this both on a desktop AIR app and on the browser if possible. Any help or advice would be much appreciated. Regards, Andrew.

2 1

Updating the tradition for new reviewer blog posts
by Tony Gentilcore 03 Aug '10

03 Aug '10

The Surfin' Safari blog seems to have fairly wide readership in the web dev community. Google Reader reports 35k Reader subscribers. For comparison: blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last post with descriptive content was back on April 18th. Since that post, we've written 8 "X is a now a WebKit reviewer" posts. One recent commenter said: *"I don’t suppose there’s anything more interesting going on in WebKit land worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t nearly as interesting as whatever new hotness is coming down the pipe. And I know I’m not the only one who thinks so… Feel like blogging about WebKit awesomeness?"* I propose we increase the amount of blogging about WebKit awesomeness by changing the tradition for new reviewer posts. Instead of defaulting to: * So-and-so is now a WebKit reviewer* * Posted by Someone-else So-and-so has worked on awesome-feature or awesome-infrastructure...* We encourage (or just allow?) a format more like: * How awesome-infrastructure works* * Posted by So-and-so, the latest WebKit reviewer Here's my description of how awesome-infrastructure works in WebKit...* * * * -OR- * * ** Awesome-feature is the new hotness* * Posted by So-and-so, the latest WebKit reviewer Web developers can now use awesome-feature. Here's how it works...* Thoughts? -Tony

6 8

Safari for Windows symbol server updated
by Adam Roben 02 Aug '10

02 Aug '10

The Safari for Windows symbol server has been updated with symbols for all releases through Safari 5.0.1. You can find instructions for using the symbol server at <http://developer.apple.com/internet/safari/windows_symbols_agree.html>. -Adam

1 0

commit-queue switching to Snow Leopard this week
by Eric Seidel 02 Aug '10

02 Aug '10

- CQ will block on the SL Release builder - CQ will test on SL Release before committing. Most users shouldn't notice or care. Email me if you have questions. -eric

1 0

Printer font is different from screen font
by Shinichiro Hamaji 02 Aug '10

02 Aug '10

Hi, I've noticed WebKit uses slightly different font size for printing on Mac. My colleague told me Mac's font API has a feature to select the best font for printing. This feature isn't good for a team in Google because they want exactly same results between screen and printing. I searched a workaround for this, but I couldn't find. I'm not sure if it actually improves the printing results, so it would be best if we can remove this code (FontDescription::usePrinterFont). But I guess this proposal will be objected :) Another proposal is adding a -webkit prefixed CSS property to allow users to customize the behavior. Like -webkit-font-media: auto | printer | screen (auto is the default) I'm not sure if this is a good name though. Does this plan sounds good? If so, we'd like to start implementing this. Any comments will be really appreciated. Thanks!

2 2

Re: [webkit-dev] Sharing WebKit mocks across platforms
by Adam Barth 02 Aug '10

02 Aug '10

WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath <satish(a)google.com> wrote: > With a WebCore::LayoutTestController, would there be a need for code in > WebKit to convert the call parameters from WebKit types (which DRT uses) to > WebCore types (which the mocks may use) ? If yes seems like we need wrappers > to proxy the mock calls anyway on different platforms.. > Cheers > Satish > > > On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth <abarth(a)webkit.org> wrote: >> >> Thanks for bring this question to the list. I don't have a strong >> opinion here, but I want to make sure we think project-wide and pick >> something scalable. >> >> This discussion is also related to the discussion about adding >> something like a layoutTestController object to WebCore. Plumbing >> this mock API all the way through WebKit for each port seems like a >> waste. If we had something like a WebCore::LayoutTestController, it >> would make a lot more sense to expose that functionality there. >> >> Adam >> >> >> On Wed, Jul 28, 2010 at 11:30 AM, Steve Block <steveblock(a)google.com> >> wrote: >> > I'm in the process of adding a mock client for DeviceOrientation, >> > which will be used in DumpRenderTree to test the feature. In order to >> > share the mock across platforms, I'd like to add the mock to >> > WebCore/platform/mock. >> > >> > An interface to the mock will have to be exposed to the embedder >> > through the platform's WebKit API, so that it can be configured by >> > DRT, eg ... >> > >> > mWebView.getDeviceOrientationClientMock().setOrientation(...); >> > >> > To avoid each platform having to produce it's own WebKit wrapper for >> > the mock, I'm considering adding a common WebKit wrapper, perhaps to >> > WebKit/common, and I wanted to get some feedback on the idea. The mock >> > would be shared between all C++ WebKit platforms. (Note that this is >> > for convenience only, a platform could equally use it's own WebKit >> > wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or >> > use its own mock altogether.) >> > >> > Of course we also need WebKit wrappers for all of the non-POD types >> > used by the mock's interface, and these have to be common between all >> > platforms. One obvious potential difficulty is the wrapper for >> > WebCore::String. Each platforms already has a wrapper for this type, >> > but there's no guarantee of interoperability, so we'd need to write a >> > new common interface if we're to use the string type. >> > >> > If a wrapper for string ends up being too problematic, the approach >> > could still be used for mocks that don't need the string type (of >> > which DeviceOrientation is one), but the approach then seems less >> > compelling. >> > >> > Do people think that this is a reasonable proposal and worth pursuing? >> > Has there been any attempt to do anything similar before? Or is any >> > attempt to write this kind of common WebKit code not worth the effort >> > and destined to failure? >> > >> > You can see the work in progress for DeviceOrientation at >> > https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for >> > SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 >> > >> > I'd appreciate any feedback you may have. >> > >> > Thanks, >> > Steve >> > >> > -- >> > Google UK Limited >> > Registered Office: Belgrave House, 76 Buckingham Palace Road, London >> > SW1W 9TQ >> > Registered in England Number: 3977902 >> > > >

5 8