[webkit-dev] Haptics CSS extension

[kim.1.gronholm]

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

[Mario Bensi]

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.

[Mike Marchywka]

> 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

[Alex Milowski]

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

[Simon Fraser]

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 
) 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?

[Alex Milowski]

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

[Geoffrey Garen]

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

[Alex Milowski]

On Tue, Jun 22, 2010 at 6:06 PM, Geoffrey Garen  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

[Darin Adler]

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

[Geoffrey Garen]

> 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?

[Darin Adler]

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.

[Leo Meyerovich]

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