July 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

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

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

SIL Open Font License and WebKit
by Alex Milowski 10 Sep '10

10 Sep '10

We have a licensing issue we need to address for MathML. We need the STIX fonts as they will provide consistent rendering for Mathematics. I highly suspect these fonts will find themselves on our desktops somewhere down the road. Meanwhile, we need them for our testing infrastructure to actually work across all the platforms. The STIX Fonts are available under the SIL Open Font License: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL_web You can see the patch that adds these fonts here: https://bugs.webkit.org/show_bug.cgi?id=41961 I think we need to adjust our licensing policy to include font licenses like the above. It is unlikely that the STIX consortium will change their font licensing. In reality, they don't need to do so. The font license is intended to support "open source" fonts. -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics

8 20

[svg] rect with invalid stroke value
by Yuzo Fujishima 08 Sep '10

08 Sep '10

Hi, SVG gurus, I have a question regarding LayoutTests/svg/custom/invalid-fill-hex.svg . It contains: <rect width="100" height="100" fill="#ff" stroke="#0"/> From the comment there I understand that the rect should be filled with black. But how about the stroke? I guess black stroke should be rendered, because #0 is also invalid. Is it true? The current test data (expected output) doesn't contain the stroke. I'm asking this https://bugs.webkit.org/show_bug.cgi?id=24742 fixes hex color parsing and as a result, the stroke above starts to be rendered with black. I'd like to find out whether the above test (or test data) is wrong or I am making a mistake. I think we should either: Rewrite <rect width="100" height="100" fill="#ff" stroke="#0"/> to <rect width="100" height="100" fill="#ff"> or rebaseline the test data. Which do you prefer (assuming the test needs to be changed?) Yuzo

5 10

A proposal for "Platform Mechanisms"
by Anders Carlsson 17 Aug '10

17 Aug '10

Hi everyone, We've now reached the point in WebKit2 development where we need to be able to override some global calls in WebCore so that we can funnel them through to another process, in a similar way to what Chromium does. We also need to be able to override the calls at run-time, so that we can use the same WebCore framework with both current WebKit and WebKit2. Here's a proposal for something I call "Platform mechanisms" that I hope can be used by other ports as well as replacing the Chromium bridge long term: The design pattern we use in WebCore for when a port wants to override functionality is the "abstract client class" pattern. We have a FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality is global, and doesn't really belong to a specific object, for example: * Clipboard handling * File access * Plug-ins. I propose that we create an abstract class, "PlatformMechanism" which acts as the starting point for accessing such functionality, something like: class PlatformMechanism { virtual ClipboardMechanism* clipboardMechanism() = 0; virtual FileAccessMechanism* fileAccessMechanism() = 0; virtual PluginMechanism* pluginMechanism() = 0; }; class PluginMechanism { virtual void refreshPlugins() = 0; virtual void getPluginInfo(Vector<PluginInfo>&) = 0; }; The various ports would subclass PlatformMechanism, implement the various mechanism classes and then call into WebCore to set the PlatformMechanism. This approach gives a natural separation of the functionality. (There's of course nothing stopping you from having a single class inherit from all of the mechanism classes). We could also consider adding some functions to PlatformMechanism directly, for example if a mechanism class would end up with just a single function. The advantage of having a single "PlatformMechanism" aggregator class is that we don't need lots of setFooMechanism calls that ports would need, and if someone adds a new mechanism class, ports will fail to build instead of mysteriously crash when it turns out someone has forgotten to add a call to set the mechanism. We would also provide WebCore implementations of the various mechanisms, so that ports that don't want to override anything would just return the WebCore mechanisms. We could even have a WebCorePlatformMechanism class that you could set as the default class. This would enable ports to pick where WebCore should be used. I would very much appreciate any comments on this, and if I don't hear any major objections I will start landing parts of this, conditionally compiled by a WTF_USE_PLATFORM_MECHANISM define that's turned on for Mac WebKit. Thanks, Anders

12 20