April 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

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

webkit-patch, check-webkit-style and git now support --squash and --git-commit
by Ojan Vafai 09 Jul '10

09 Jul '10

The behavior of git and webkit-patch changed with http://trac.webkit.org/changeset/58261. Many webkit-patch commands (e.g. upload and land) and check-webkit-style now take --squash and --git-commit arguments. --git-commit: upload, commit, check-style, etc on the given git commit(s). Commits can be specified as single commits (e.g. HEAD^) or mulitiple (e.g. HEAD~2..HEAD). check-webkit-style's sense of --git-commit is no longer all patches since the commit and --git-since is removed. The equivalent to the old check-webkit-style behavior is "--git-commit=HEAD~2.." instead of just using HEAD~2. --squash: Treat all changes in the local branch as a single patch (local commits + working copy changes). Doesn't actually modify your tree until you land, at which point it squashes all local changes into a single local commit and then lands that. --no-squash: Treat all changes as separate. This is essentially just "git svn dcommit". Each local change is committed separately. If you leave out --squash and --no-squash, then something resembling the old behavior is used. old-behavior: upload, diff, create-patch, etc. only considered working-copy changes and land will commit working-copy changes and then commit each local commit separately. new-behavior: is roughly like the above, except if there's only a single local commit and no working-copy changes, then the commands will work on that single local commit and otherwise raise an error. Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. Finally, if you get sick of typing --squash or --no-squash, you can set the webkit-patch.squash git config parameter to true/false. Ojan

8 17

beforeinput and input events for contenteditable/designMode
by Ojan Vafai 17 Jun '10

17 Jun '10

We'd like to implement this event and want to make sure there's no opposition before moving forward. I don't expect this to require huge rewrites to current webkit code, but it will definitely require some plumbing to make it so that all user-gestures that modify the DOM go through this codepath. The proposal is that the input event be fired for any user-gesture that results in a modification to the DOM. This matches the input event for text controls. We'd like to add an 'action' property (open to better names) that indicates what the user-gesture was (e.g. paste, deleteword, undo, inserttext, etc). The goal is to simplify monitoring of changes to rich-text regions and to enable use-cases where the data is stored in a different model than HTML. This is needed so that, for example, an undo operation can be applied correctly on the model as well as the DOM. The beforeinput event would fire before the DOM is modified and is cancelable. I don't think this should be too much more work than adding the input event, an exception might need to be made for IME input here though. Specifically, it might be hard to make IME events cancelable. More details: https://bugs.webkit.org/show_bug.cgi?id=26526 Initial whatwg thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020553.html Hixie's response: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021101.html Ojan

2 3

Increasing the number of cross-platform/port expected results
by Tor Arne Vestbø 21 May '10

21 May '10

Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. We're seeing this in the Qt port when results are checked in as platform-independent and causing failures, or when we have to generate platform-dependent results for new tests when the test looks cross-platform. I also had this problem when trying to get a Windows build up and running with 0 failing layout-tests, so that I could verify that I didn't break anything before landing. Even after using various tricks to get the same font setup as the buildbots I still had failures that looked like they were due to font metrics [1]. Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. Another approach would be to use a fixed set of metrics for text and themes when running the DRT, unless the test specifically asks for real font and theme metrics. We could for example add two additional functions to the layout-test controller: layoutTestController.dumpRealFontMetrics() and layoutTestController.dumpRealThemeMetrics() This would allow us to share render-tree results between all ports for those tests that don't explicitly test font or theme rendering (unless I missed more platform-differences). Thoughts? Will this work? :) Or, are there other ways we could achieve the same thing? My worry is basically that the number of platform-specific-result will not scale as the number of ports and platforms increases if we continue to have all these "false positive" platform-specific-results that are not really platform-specific. Tor Arne [1] http://trac.webkit.org/wiki/BuildingOnWindows#RunningtheLayoutTestsonWindows

18 29

JSC String re-factorings are hosing the tree.
by Eric Seidel 08 May '10

08 May '10

A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -eric

9 17

Re: [webkit-dev] Announcing WebKit2
by Alfonso Guerra 05 May '10

05 May '10

Pardon me for the late entry into this conversation, but as you'll be discussing this tomorrow in your meeting I wanted to add my perspective as a Mac developer for your consideration. Since I'm new on the list, a little background info to help understand that perspective. Like thousands of developers out there, I have a notebook app. This app, named Mori, is being upgraded from letting users create content strictly as rich-text notes to holding PDFs, web archives, and various other document types. The document type UI and programmability is contained within plugins which I and third-party developers have created. When Chromium was announced, its feature of forking each web page into a separate process struck me as an intelligent way to deal with plugin security, and I anticipated adding such functionality to Mori in a future release. Now with the arrival of WebKit2 Apple's advocating process management at an API level lower than content-handling, instead promoting a process API that while not invisible to the host app would seem to make it more difficult to cleanly manage processes for web-content types and non-web content. Or do I not fully understand the functionality provided by WebKit2 and WebCore (which I freely admit I do not)? Will I be able to fork and manage non-WebCore processes through this API? Will I be able to adjust process priorities to keep all processes of a certain MIME type (say application/x-shockwave-*flash) to receive no more than 15% cpu time or monitor its memory usage? Do I need to subsume all my app's content-related functionality into WebKit to cleanly inherit the process model or else implement another Chromium-like process management layer on top for non-web content and still oversee the sub-API processes of WebKit2's scheme?* On Fri, Apr 9, 2010 at 11:24 AM, Maciej Stachowiak <mjs at apple.com <http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev>> wrote: > Simply put, Chromium WebKit did not provide what we needed to build an > API that handles multiprocess and can sanely be used by many > applications. While we could have built the WebKit2 API on top of > Chromium WebKit, that would just be an unnecessary level of > indirection compared to building on WebCore, and would not help us > solve the technical challenges involved. I would think there are more technical and performance challenges involved in the IPC in the middle of the stack rather than at the top, but I'm not yet acquainted with how you've factored out the processes. > It was a reasonable choice for Google to build multiprocess and > sandboxing outside WebKit instead of inside, given that Chrome started > as a secret project, and you have no other clients for your API. But > it makes the Chromium multiprocess code fundamentally not reusable for > other WebKit clients or other WebKit port. With WebKit2, we are > looking to build reusable multiprocess. I believe Mori, and other rich-media (or multimedia or whatever we're calling it now) apps such as it, provide sufficient examples where that isn't to be the most likely case. > I hope this post clarifies why the Chromium WebKit port is not really > a viable solution for our needs as it stands today. Not really. As a host-app developer, I can't justify supporting 2 process models for content handlers in my app in this way. And excepting purely web-browsing apps, I don't see the benefit over the Chromium model to apps which provide users access to other types of content. As I said before, I'm not well-versed with WebKit's architecture nor the issues the WebKit2 team have been tackling that led them to see this path as the most practical manner in which to proceed. And WebKit has its clients, inside and outside of Apple, to answer to for which I'm owed neither an explanation nor alteration of the team's roadmap (or anyone else's from the community, for that matter).

5 4