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

Is it OK to remove Frame::setIsDisconnected() and isDisconnected() ?
by Sverrir Á. Berg 09 Apr '12

09 Apr '12

Working on a change in FrameTree and noticed that the checks in top() and parent() for 'checkForDisconnectedFrame' rely on a flag in Frame that as far as I can tell is never set.So my naive question is: Can I remove the corresponding code from Frame and FrameTree? If not I would like if somebody could explain how they are used so I don't break anything with my change. More detail: * My search for calls to Frame::setIsDisconnected reveals no callers in WebKit, Chromium or Google code search. * This functionality is disjoint from Frame::disconnectOwnerElement(). Thanks, Sverrir

4 6

Throwing SECURITY_ERR on cross-origin window.location property accesses
by Mihai Parparita 27 Mar '12

27 Mar '12

I was wondering if it would be a reasonable change to make accessing location.href (and other location properties) throw SECURITY_ERR when accessed across origins (https://webkit.org/b/43504) This initially was reported on the Chrome side (http://crbug.com/17325) but it looks like neither the JSC nor V8 bindings do this, so fixing it across the board seemed reasonable. >From my investigations, it looks like IE and Gecko both throw an exception in this case, and the HTML5 spec mentions it too ( http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#se… ). I realize that we're cautious around the access checks for security reasons (based on changes like https://trac.webkit.org/changeset/48619) but this seems safe since 1) we were returning control to the script at that point anyway 2) we already throw exceptions in some cases in that code: https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.… Thanks, Mihai

8 20

Accelerated 2D Tesselation Implementation
by Chris Marrin 03 Mar '12

03 Mar '12

Hi Ken, It would help me, and I think many others, if we could have a discussion of how exactly your tessellation logic works and what it is intended to do. For instance, is the algorithm you're using based on Loop-Blinn? I'm a bit familiar with that algorithm and some of the problems it has with rendering this type of geometry. For instance, there are typically anti-aliasing artifacts at the points where the interior triangles touch the edges. These are described in section 5.1 of the paper and the authors added additional (and not well described) logic to solve the problem. If you could describe your algorithm a bit and show some expected results with typical cases, that would be really helpful. For those not familiar with Loop-Blinn, here is a link to their original paper, presented at Siggraph 2005: Resolution Independent Curve Rendering using Programmable Graphics ... It's a great algorithm for rendering resolution independent 2D objects using the GPU. It has potential to render both 2D shapes (as used in Canvas and SVG) and text glyphs. It's advantage is that once you generate the triangles for the shape, you can render the shape at any resolution. It's disadvantage is that the triangle generation is quite expensive, so mutating shapes can potentially be slower than a simpler resolution dependent tessellation. ----- ~Chris cmarrin(a)apple.com

6 17

ImageLoader class
by Sergiy Byelozyorov 09 Jul '11

09 Jul '11

Hello, I am writing my own class using ImageLoader. Can somebody, please, help me with these questions: 1. How do I know that the image was loaded already? Can I set up callback somehow? 2. What should functions sourceURI() and dispatchLoadEvent() do? 3. What is pixel format for m_imageLoader.image()->image()->data()->data()? Is this the right way to access loaded image raw pixel data? 4. How can I handle animations (e.g. GIF files)? How do I know when the next image in the animation suquence is ready? Another callback? 5. Which image formats are supported? Can I add my own, like HDR? Thank you. Sergiy

1 1

parallel painting
by Zoltan Herczeg 10 Jun '11

10 Jun '11

Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan

8 10

WebKit blog post proposal: Remote debugging with Web Inspector.
by Pavel Feldman 02 May '11

02 May '11

Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? Thanks Pavel

12 17

WebKit2 build system
by Balazs Kelemen 11 Apr '11

11 Apr '11

Hi folks! While I worked on the Qt port of WebKit2, I faced with some build issues. To solve these problems it seems like common parts of WebKit2 should change, that is why I thought that discussing them in the list would be useful. There are two main problem I see: * Usage of precompiled header. Without using WebKitPrefix.h as a precompiled header it seems like includes are broken. The reason why I dislike precompiled header is that distcc does not support it. * Include paths. The common files in WebKit2 includes headers in the form #include <WebKit2/xyz.h> while the real place of the file is for example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by copying headers into the build dir and set the includepath to contain it, but I do not think it is a good practice. I think WebKit2 would be more portable if we could solve these problems. Please share your thoughts with me!

6 5

Sharing WebKit mocks across platforms
by Steve Block 11 Nov '10

11 Nov '10

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 7

New requirement for building on Windows coming
by Chris Marrin 19 Oct '10

19 Oct '10

I've submitted a patch for accelerated compositing support on Windows. I hope to land it today. When I do it will require d3d9.lib to link. The feature will be turned off at first, but the build still needs to find the library. So the build-bots will need to be updated with DirectX 9.0 SDK Update (December 2004): http://www.microsoft.com/downloads/details.aspx?FamilyId=4E825A37-0C94-4421… You'll also need to add a path to this SDK in your MSDev Include and Library paths. The WebKit build-bots have already been updated, but external ones should make the changes in preparation. I'll br adding this info to webkit.org today. ----- ~Chris cmarrin(a)apple.com

6 11

Re: [webkit-dev] Announcing new port: EFL
by haithem rahmani 05 Oct '10

05 Oct '10

Hi, Just a simple question: - It seems that the EFL port of webkit is based on EFL/X11 api. is there plans to support other EFL backends especially directfb ? WebkitGtk is doing that with (--with-target=directfb) option. regards. Haithem. -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him.

2 2