June 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

[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

About fixing "old" layout bugs
by Xianzhu Wang 11 Aug '10

11 Aug '10

Hi, I'm new to webkit development, and I'd like to hear opinions about the problems I met. Now I'm trying to fix some "old" layout bugs, for example: * white space preceding <br> ( https://bugs.webkit.org/show_bug.cgi?id=37261) * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) * line breaking around some punctuations ( https://bugs.webkit.org/show_bug.cgi?id=37698) Some people have warned me about the difficulty of fixing these bugs, and now I have realized it. Fixing the bugs themselves is not very difficult, for example, only 2 functional lines change can fix the first bug. However, the change will break more than 4000 existing layout tests mostly because trailing spaces preceding <br>s in current expectations of the tests (for example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests (for now on mac only), and the patch is about 6MB (Sorry I overlooked the "Bigfile" option when I submitted the patch, so I split it into 4 parts). My questions are: 1. The bugs violate the standards and cause some site compatibility issues. However, because the bugs are old, some web developers might treat them as features and depend on them, so fixing them might break some existing pages. Is there any existing policy about this problem? Are these bugs worth fixing? 2. What's the best practice to deal with a patche containing many updated layout test expectations? Is there a good way to rebaseline the effected tests on all platforms? Thanks, Xianzhu

5 9

strategy for evaluating performance issues related to memory.
by Mike Marchywka 10 Aug '10

10 Aug '10

So where does this stand right now? I hope to actually contribute at some point. but right now I'm just trying to determine approaches to even finding the problems. ( and yes my disk light still comes on for minutes at a time locking me out of doing antyhing with iceweasel or firefox) I guess at a gross level it would be nice to know when and why page faults occur but a more pro-active approach would be to start understanding the memory needs during design or code examination for other reasons. If there is nothing better, perhaps people could put in formatted comments about memory needs and access patterns and various parameters or issues or assumptions that in the code. I haven't entirely thought this through (duh) and hope to stimulate a discussion ( actually I'd be happy if someone had a one line answer or link to an answer but am not that opitmistic). I would approach this as an addition to finding memory leaks but maybe the worst offenders will go away if there is less clutter. Thanks. - - - - - - Mike Marchywka | V.P. Technology 415-264-8477 marchywka(a)phluant.com Online Advertising and Analytics for Mobile http://www.phluant.com note new address Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)<- use this 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka(a)hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

6 10

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