[webkit-dev] Haptics CSS extension
We at Nokia have implemented tactile feedback (i.e. Haptics) support for touch-based user interfaces and are now ready to land the implementation to the WebKit trunk. Since the real-time requirements of a realistic feel are very tight, it is not possible to implement the haptic feedback via a simple javascript event handler. We have considered various alternatives and concluded that the best and most future-proof way is to utilize CSS to specify the tactile feedback style of a web element. Thus, we implemented a -webkit- CSS extension that enables web developers to specify the feel of an element. This is important for custom JavaScript controls to behave identically to native controls. The specification is currently at http://www.starlight-webkit.org/CSS/css3-haptics.html and the implementation work is ongoing at https://bugs.webkit.org/show_bug.cgi?id=40263. We have also been discussing about this at www-style mailing list to get feedback. We are actively driving the standardization with the Nokia standardization team and will make any necessary changes of the final standard, if any. As it is likely that this extension will be used mainly by JavaScript libraries, we are not too concerned about the potential legacy the standardization may introduce. Finally, the haptic feedback of web elements will be implemented in Nokia smartphones and we would like to commit the implementation to the open source even before product launch. All feedback would be more than welcome! Br, Kim Grönholm ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] PLATFORM_STRATEGIES
Hi all, In revision 61429, you have introduced PLATFORM_STRATEGIES and you define WTF_USE_PLATFORM_STRATEGIES. It should be ENABLE_PLATFORM_STRATEGIES, no ? Best Regards Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] strategy for evaluating performance issues related to memory.
CC: webkit-dev@lists.webkit.org From: ddkil...@webkit.org Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. Date: Mon, 21 Jun 2010 19:44:53 -0700 To: marchy...@hotmail.com On Jun 21, 2010, at 6:21 AM, Mike Marchywka wrote: (and yes my disk light still comes on for minutes at a time locking me out of doing antyhing with iceweasel or firefox) Two things: 1. What hardware platform and O/S are you running a WebKit browser on that still uses a disk light? (Do PC cases still have disk lights? I guess I haven't looked recently.) I've got a 500Mb laptop with firefox on XP and a 1Gb system running debian with iceweasel. 2. Why do you keep mentioning Iceweasel and Firefox? Those browsers are based on Mozilla's Gecko engine, not WebKit. Those are what I'm using where I see a problem but it seems just about any apps these days have similar issues. I have no idea how the codes or architectures compare but normally ideas seem to diffuse, code and algorithms get copied, and common problems recur. I wanted to use webkit for some specific things, hope to contribute, and many have mentioned memory issues here too. This is just something I'd like to avoid unless it is already a known non-problem. I guess I could go get Chrome and try it out. Dave _ 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:WL:en-US:WM_HMP:042010_1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Interpreting LEAK: on Shutdown
I looked at this document on the wiki: http://trac.webkit.org/wiki/Memory%20Use and I'm curious about how to interpret the output on the console when running via Safari. For example, here's one output when I just quit with windows open: LEAK: 2 WebCoreNode LEAK: 29 CachedResource Here's another when all the windows were closed: No leak checking done: At least one WebView is still open. I'm particularly interested in whether the MathML code is leaking. I don't have any direct concerns but I want to understand how to check my rendering object implementations. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Haptics CSS extension
On Jun 22, 2010, at 12:44 AM, kim.1.gronh...@nokia.com wrote: We at Nokia have implemented tactile feedback (i.e. Haptics) support for touch-based user interfaces and are now ready to land the implementation to the WebKit trunk. Since the real-time requirements of a realistic feel are very tight, it is not possible to implement the haptic feedback via a simple javascript event handler. We have considered various alternatives and concluded that the best and most future-proof way is to utilize CSS to specify the tactile feedback style of a web element. Thus, we implemented a -webkit- CSS extension that enables web developers to specify the feel of an element. This is important for custom JavaScript controls to behave identically to native controls. The specification is currently at http://www.starlight-webkit.org/CSS/css3-haptics.html and the implementation work is ongoing at https://bugs.webkit.org/show_bug.cgi?id=40263. We have also been discussing about this at www-style mailing list to get feedback. We are actively driving the standardization with the Nokia standardization team and will make any necessary changes of the final standard, if any. As it is likely that this extension will be used mainly by JavaScript libraries, we are not too concerned about the potential legacy the standardization may introduce. Finally, the haptic feedback of web elements will be implemented in Nokia smartphones and we would like to commit the implementation to the open source even before product launch. All feedback would be more than welcome! My impression from the thread on www-style (starting here http://lists.w3.org/Archives/Public/www-style/2010Jun/0389.html) was that there was very little consensus over the haptic feedback-related CSS properties. I think it's premature to land an implementation in WebKit until the specification has been more widely discussed, and has a greater degree of acceptance. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Component in Bugzilla?
Could someone create a MathML component for bug reports in Bugzilla? Please? -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Interpreting LEAK: on Shutdown
Hi Alex. I looked at this document on the wiki: http://trac.webkit.org/wiki/Memory%20Use and I'm curious about how to interpret the output on the console when running via Safari. For example, here's one output when I just quit with windows open: LEAK: 2 WebCoreNode LEAK: 29 CachedResource Those messages indicate that some objects were not deleted before shutdown. Ensuring that all known references are released before shutdown, and then verifying that all objects are deleted, is an aid to debugging memory leaks. But the mechanism to ensure that all known references are released before shutdown seems to have bit-rotted a bit. Maybe you can fix it. Best, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Interpreting LEAK: on Shutdown
On Tue, Jun 22, 2010 at 6:06 PM, Geoffrey Garen gga...@apple.com wrote: Those messages indicate that some objects were not deleted before shutdown. Ensuring that all known references are released before shutdown, and then verifying that all objects are deleted, is an aid to debugging memory leaks. But the mechanism to ensure that all known references are released before shutdown seems to have bit-rotted a bit. Maybe you can fix it. OK. But how do you avoid this: No leak checking done: At least one WebView is still open. If you quit all the windows you still get it. In general, the documentation on all this is a little sparse. -- --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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Interpreting LEAK: on Shutdown
On Jun 22, 2010, at 1:30 PM, Alex Milowski wrote: But how do you avoid this: No leak checking done: At least one WebView is still open. There’s no real need to avoid that one. It’s just advisory. If you quit all the windows you still get it. If you get it even after closing all windows, it’s probably a bug. In general, the documentation on all this is a little sparse. There is no documentation that I’m aware of. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Interpreting LEAK: on Shutdown
OK. But how do you avoid this: No leak checking done: At least one WebView is still open. Originally, this message was about fast shutdown. An application choosing not to close all windows / WebViews before termination would emit this message, which was slightly clearer than mysterious LEAK messages. If you quit all the windows you still get it. Seems like a bug. Like I said, I think there's been some bitrot in this area. The best way to track down this bug is probably to set a breakpoint on WebView allocation and destruction, and log backtraces. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MathML Component in bugs.webkit.org?
On Jun 22, 2010, at 8:28 AM, Alex Milowski wrote: Could someone create a MathML component for bug reports in Bugzilla? Sure, I added it. I hope it’s helpful to have a separate component for this. I’m not entirely sure we get a lot of value out of the separate bugs.webkit.org components we currently have. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] strategy for evaluating performance issues related to memory.
I've been doing some memory benchmarking recently (my current interest is layout but am also poking at nearby processes). Generally, data representation seems hard to usefully tweak in a non-invasive way as it's pretty good while being legible (e.g., bit packing), but access patterns (and random allocations) already seem questionable. This especially hurts netbooks/mobiles, but I'm seeing high missrates on my penryn MacBook Pro and it likely surfaces in the new macbook pros with their big L3 but much smaller L2 (though I can't get perf counters w/ Shark to work there). A high-impact and less-painful first step might be to target CSS selectors default render style creation: -- buffer calls at the end of the parseToken()-insertNode()-attach()-createRender()-styleForRenderer()-styleForElement() pipeline -- once enough are in (or there is nothing else to do), perform matchRules/matchUARules calls: -- in tiles -- ... and in parallel -- ... and with software prefetching -- resume rest of createRender calls (similar tricks may apply, still not sure) A different form of this is now in the firefox mainline but there's room to do more using the above (and I suspect with a bit less implementation complexity). Anyways, this seems inappropriate for this list, but if anybody would be interested in continuing the discussion, you have my email. Also, if there are any resources describing memory layout / instantiation / etc. patterns and how/why recomputation/memoization are traded off, it would be a nice bootstrap: I've been essentially walking through http://webkit.org/blog/114/webcore-rendering-i-the-basics/, seeing how the code deviates or specializes, and profiling it with Shark Instruments. Regards, - Leo On Jun 21, 2010, at 9:05 PM, Maciej Stachowiak wrote: On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote: I was hardly worried about who does anything as much as what would make sense to do. I have interest, motivation, and multiple copies of the code but not a lot of time to waste of bad approaches. There was a prior discussion about coding conventions that should be applicable even to those contemplating a contribution of just browsing the code, I fail to see how this discussion is less relevant to current and possible future development concerns. If there was some piece of this or a related effort that could be aided by certain code features that would seem to be of interest to everyone and it isn't clear which people would have important thoughts to contribute ( or I would take it some other place). So I take it that now you just have factories and smart pointers and just make stuff and have it allocated wherever without further thought? I guess I could do some profiling my self and empirically find problems and just assume that no one has specific comments on suspects or things they have observed as possible problems. In my experience with performance work, and specifically in the context of WebKit, I believe the following are useful approaches to reducing memory use: 1) Find and fix memory leaks. There are good tools for this, and memory leaks contribute considerably to memory growth over a long browsing session. Long-term memory growth is a bigger concern than one-time costs or per-page memory that is properly returned to the system. 2) Run memory profiling tools under a significant and realistic workload, such as Mozilla's membuster test. We have had great success with this and in particular you can find some good recent memory use improvements from Sam Weinig and Anders Carlsson, among others, if you look at the ChangeLog. 3) Track memory benchmarks regularly, and identify and fix regressions. 4) Run long automated page loads to verify that memory growth stabilizes eventually, rather than continuing to grow without bound. 5) Investigate memory held by caches, and figure out ways to get the same speed benefits with less overall memory use, for example by discarding redundant data or better tuning the cache to hold the items most likely to be reused. 6) Find reproducible cases of non-leak repeatable memory growth, and determine where the extra memory is going. If you are interested in improving WebKit's memory use, I encourage you to consider one or more of the above approaches. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
