Re: [webkit-dev] setTimeout as browser speed throttle
I think you've already seen this, but in case you haven't - here is the bug where I've been tracking this. Every report I've seen related to minimum timers is referenced in here. http://code.google.com/p/chromium/issues/detail?id=792 I think the evidence is pretty compelling that 10ms and 1ms is a better value. Mike On Tue, Sep 30, 2008 at 11:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:36 PM, Darin Fisher wrote: On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: ... 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? We are in the process of verifying this now ;-) Our eyes and ears are open (have been) for bug reports related to this. Right now, we are happy to be trying something radical. In the absence of problem reports, when do we declare success? Based on what Peter said, it sounds like there has been at least one problem report. There was at least one more vague report made informally in John Resig's blog comments. Maybe we need to start by agreeing what counts as absence of problem reports. However, by way of comparison, we added a 10ms clamp three and a half years after the first Safari beta was released to the public, as it took about that long to get enough bug reports to convince us that we had to do it for compatibility. Given that, I think we may want to find some more active way to look for potential problems and potential benefits. 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
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 11:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:36 PM, Darin Fisher wrote: On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: ... 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? We are in the process of verifying this now ;-) Our eyes and ears are open (have been) for bug reports related to this. Right now, we are happy to be trying something radical. In the absence of problem reports, when do we declare success? Based on what Peter said, it sounds like there has been at least one problem report. There was at least one more vague report made informally in John Resig's blog comments. Maybe we need to start by agreeing what counts as absence of problem reports. However, by way of comparison, we added a 10ms clamp three and a half years after the first Safari beta was released to the public, as it took about that long to get enough bug reports to convince us that we had to do it for compatibility. Given that, I think we may want to find some more active way to look for potential problems and potential benefits. Regards, Maciej I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. My point was just that we wanted to feel the pain ourselves before going a similar route. We have yet to feel the pain substantially, and so it is interesting to keep going, gathering more data points. (Our architecture is designed to allow users to see that it is a particular website that is misbehaving and so we have a lot of opportunity I think to raise the visibility of things like this and to at least gather more data.) -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] changes to gtk+ port
ScrollView is undergoing heavy refactoring right now to make it more cross-platform (to enable all ports to share a lot more of the code). The code in question just moved (today) into the chrome clients over on the WebKit side. WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp The method responsible for doing repaints now is: void ChromeClient::repaint(const WebCore::IntRect windowRect, bool contentChanged, bool immediate) I encourage someone to double check my work to make sure I kept the logic the same when moving the Gtk code over. dave ([EMAIL PROTECTED]) On Oct 1, 2008, at 2:54 AM, Luka Napotnik wrote: Hello. I have a patch that modifies the update behavior for WebKit. The code was usually in WebCore/platform/gtk/ScrollViewGtk.cpp. The missing code invalidated the GdkWindow and processed updates with the code that was in the method ScrollView::updateContents: - if (window) gdk_window_invalidate_rect(window, rect, true); // Cache the dirty spot. addToDirtyRegion(containingWindowRect); if (now window) gdk_window_process_updates(window, true); - But now I'm unable to find the code. Any hint where this updating has been moved to. Please help. Greets, Luka ___ 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
Re: [webkit-dev] changes to gtk+ port
Oh, by the way https://bugs.webkit.org/show_bug.cgi?id=21083 is the bug tracking the ScrollView refactoring. dave ([EMAIL PROTECTED]) On Oct 1, 2008, at 3:06 AM, David Hyatt wrote: ScrollView is undergoing heavy refactoring right now to make it more cross-platform (to enable all ports to share a lot more of the code). The code in question just moved (today) into the chrome clients over on the WebKit side. WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp The method responsible for doing repaints now is: void ChromeClient::repaint(const WebCore::IntRect windowRect, bool contentChanged, bool immediate) I encourage someone to double check my work to make sure I kept the logic the same when moving the Gtk code over. dave ([EMAIL PROTECTED]) On Oct 1, 2008, at 2:54 AM, Luka Napotnik wrote: Hello. I have a patch that modifies the update behavior for WebKit. The code was usually in WebCore/platform/gtk/ScrollViewGtk.cpp. The missing code invalidated the GdkWindow and processed updates with the code that was in the method ScrollView::updateContents: - if (window) gdk_window_invalidate_rect(window, rect, true); // Cache the dirty spot. addToDirtyRegion(containingWindowRect); if (now window) gdk_window_process_updates(window, true); - But now I'm unable to find the code. Any hint where this updating has been moved to. Please help. Greets, Luka ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
In the Chrome tree, every object inheriting from RefCounted incurs an extra pointer in size, but this is clearly more than necessary since many RefCounted objects do not have bindings. If we believe that JS wrappers are relatively uncommon, we can store them in a Node's rare data structure, and bloat only those uncommon nodes that have JS wrappers. If we believe that JS wrappers are relatively common, we can store them directly in a Node, since putting them in a hashtable is net more memory use. Non-Node wrappers are another story. Perhaps they are all uncommon enough to go in a hash table. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Oct 1, 2008, at 1:46 AM, Geoffrey Garen wrote: In the Chrome tree, every object inheriting from RefCounted incurs an extra pointer in size, but this is clearly more than necessary since many RefCounted objects do not have bindings. If we believe that JS wrappers are relatively uncommon, we can store them in a Node's rare data structure, and bloat only those uncommon nodes that have JS wrappers. Depending on exactly how common they are, this could be more net memory use, if it causes Nodes to have a NodeRareData structure that wouldn't otherwise. If we believe that JS wrappers are relatively common, we can store them directly in a Node, since putting them in a hashtable is net more memory use. I think only a minority of nodes have wrappers, but on at least some pages it is likely to be a sizable minority. I did not measure though - should have. Non-Node wrappers are another story. Perhaps they are all uncommon enough to go in a hash table. I strongly suspect that is the case. On many of these sites, the number of CSSOM objects (inheriting from StyleBase) and NamedAttrMaps outnumbered the count of Nodes, and it is relatively rare to deal with such objects from JS. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] arora with webkit trunk
Hello, I've been able to build Arora using release 36309 of Webkit trunk, in order to test the netscape plugin support to see flash enabled pages. However, when I enter any page that has flash objects, Arora aborts with the following error: (process:4312): GLib-GObject-CRITICAL **: gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function (process:4312): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `GDK_IS_DISPLAY (display)' failed Adobe Flash Player: gtk_clipboard_get(GDK_SELECTION_PRIMARY); failed. Trying to call gtk_init(0,0); Segment fault Does anybody have a clue on might be happening? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Mike On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood [EMAIL PROTECTED]wrote: http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/ It's based off Adobe's flash.utils.Timer API that they have in AS3. Once I get enough WK comments, I'll see about how to get it to HTML5... --Justin Haygood ___ 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
Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:58 AM, Darin Adler wrote: On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. That's what I would propose. Then browsers can offer greater precision in the future without having to redesign the API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
We can use the histogram facility in chrome to collect data from a dev channel release. It should only take a few weeks to get good data. What exactly do we want to measure to settle on a value? Linus On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 1:24 AM, David Hyatt wrote: On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. I'm with Hyatt. The reason we are having this thread is precisely to revisit the problem. I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. That is what I was alluding to when I said it took us 3.5 years to first realize we had to add the clamp. The problems come and go, but they are consistently a problem, and it can take a while to realize it. However, the bug Mike cited seems to mention problems with the 1ms limit on some real sites: http://code.google.com/p/chromium/issues/detail?id=792. At least 5 sites are mentioned, including nytimes. I think we are converging on some good solutions (somewhat lower basic clamp, new highres API) and I regret if this thread has felt hostile to anyone. 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
Re: [webkit-dev] Proposed Timer API
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, October 01, 2008 1:02 PM To: Darin Adler Cc: WebKit Development Subject: Re: [webkit-dev] Proposed Timer API On Oct 1, 2008, at 9:58 AM, Darin Adler wrote: On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. That's what I would propose. Then browsers can offer greater precision in the future without having to redesign the API. --- Updating now. Units of seconds. Precisision is browser defined, but will be higher precision (or same precision) as setInterval/setTimeout. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
I first sent this to Mike Belshe; I meant to send it to the list, but I'm new to it: Perhaps it could use milliseconds, but allow floating-point numbers. Milliseconds would be easier, in my opinion, to work with than microseconds. Adobe's data type for delay is Number, which according to their documentation, represents a double-precision floating point number. However, they do not appear to use this precision -- although it is difficult to test; I made a test which, after waiting one second for the application to finish loading, ran a timer set for .1 milliseconds, set to repeat 100 times. The first event was a full millisecond after the timer was called, and the entire repeat (each interval was traced to the debugger) took consistently around 1700 milliseconds. For comparison purposes, I also ran it in a pure loop, and the entire loop took 4 milliseconds. As an aside, a similar test of setInterval on Webkit showed that 100 iterations completed in almost exactly 1000 milliseconds; almost precisely 10 milliseconds per interval. It seemed more consistent than Adobe's. Alex On Oct 1, 2008, at 11:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Mike On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood [EMAIL PROTECTED] wrote: http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/ It's based off Adobe's flash.utils.Timer API that they have in AS3. Once I get enough WK comments, I'll see about how to get it to HTML5... --Justin Haygood ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build error on Ubuntu Gutsy
Hi all, I'm trying to build release 37144 on Ubuntu Gutsy with WebKitTools/Scripts/build-webkit --qt. In the linkage it stops with the following error: tmp/StyleTransformData.o:(.bss._ZZN7WebCore11RenderStyle16initialTransformEvE3ops[*WebCore::RenderStyle::initialTransform()::ops]+0x0): multiple definition of `WebCore::RenderStyle::initialTransform()::ops' tmp/CSSStyleSelector.o:(.bss._ZZN7WebCore11RenderStyle16initialTransformEvE3ops[WebCore::RenderStyle::initialTransform()::ops]+0x0): first defined here ../JavaScriptCore/libJavaScriptCore.a(InternalFunction.o): In function `JSC::InternalFunction::classInfo() const':InternalFunction.cpp:(.text+0x0): multiple definition of `JSC::InternalFunction::classInfo() const' tmp/JSCounter.o:JSCounter.cpp:(.text._ZNK3JSC16InternalFunction9classInfoEv[JSC::InternalFunction::classInfo() const]+0x0): first defined here collect2: ld returned 1 exit status make[1]: *** [../lib/libQtWebKit.so.4.4.1] Error 1 make[1]: Leaving directory `/home/pedralho/svn-webkit/WebKit/WebKitBuild/Release/WebCore' make: *** [sub-WebCore-make_default-ordered] Error 2 What can I do to fix it? -- André Pedralho ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 1:46 AM, Geoffrey Garen [EMAIL PROTECTED] wrote: In the Chrome tree, every object inheriting from RefCounted incurs an extra pointer in size, but this is clearly more than necessary since many RefCounted objects do not have bindings. If we believe that JS wrappers are relatively uncommon, we can store them in a Node's rare data structure, and bloat only those uncommon nodes that have JS wrappers. If we believe that JS wrappers are relatively common, we can store them directly in a Node, since putting them in a hashtable is net more memory use. This does not have to be an all or nothing strategy. One idea we have discussed was to use different strategies for different classes based on how likely we believe they are to need a binding. For instance, if (since?) HTMLElement is more likely than Text nodes to need bindings, we could store a pointer for HTMLElements and fallback to the HashMap or RareData for Text. Regardless, I think the real blocker here is hard data. We would love to see what the V8 team has found and how they tested those findings. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
If we believe that JS wrappers are relatively uncommon, we can store them in a Node's rare data structure, and bloat only those uncommon nodes that have JS wrappers. Depending on exactly how common they are, this could be more net memory use, if it causes Nodes to have a NodeRareData structure that wouldn't otherwise. If we believe that JS wrappers are relatively common, we can store them directly in a Node, since putting them in a hashtable is net more memory use. I think only a minority of nodes have wrappers, but on at least some pages it is likely to be a sizable minority. I did not measure though - should have. I should also mention Sam's suggestion, which I think is pretty good: All HTMLElements (or perhaps all Elements) get embedded pointers to their wrappers, since JavaScript traversal of a document is relatively common. All other DOM objects, including generic nodes, use a hash table. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Javascript window.open handling in GTK
Hi, Playing around with the code for a while now I found that, at least in the GTK implementation, window.open(), close(), etc is not implemented. Can anyone explain to me why this is not implemented? Maybe because of security concerns? Wouldn't it be better to have a setting defined that restricts this feature instead of not implementing it at all?! Anyway I did my own implementation in ChromeClientGtk.cpp that actually works ok so far. However in order to make it really nice and proof I need to get a handle to the parent webview that originally started this new window. I didn't find a way yet on how to get this information down there. Can someone give me a pointer on where I can get his information from?! Main reason actually is that the parent window has to be refreshed when the child window closes. Also I want to have a safety check in the close function if the calling instance is the top level webview. Thanks! -Bernd - This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Enum naming style?
According to the WebKit style http://webkit.org/coding/coding-style.html
Names: 10. Enum members should user InterCaps with an initial capital letter.
Our enums seem to use every style imaginable:
enum EditorDeleteAction {
deleteSelectionAction,
deleteKeyAction,
forwardDeleteKeyAction
};
enum EPropertyLevel { PropertyDefault, ForceBlockProperties };
enum LengthType { Auto, Relative, Percent, Fixed, Static, Intrinsic,
MinIntrinsic };
enum CSSPropertyID {
CSSPropertyInvalid = 0,
CSSPropertyBackground = 1001,
CSSPropertyBackgroundAttachment = 1002,
enum SVGStitchOptions {
SVG_STITCHTYPE_UNKNOWN = 0,
SVG_STITCHTYPE_STITCH = 1,
SVG_STITCHTYPE_NOSTITCH = 2
};
Most of these seem wrong according to the official style. But one
point which is missing in the styleguide is what the names of the
individual values should be?
For example:
enum Color {
BrownColor,
RedColor,
BlueColor
};
Or should it be:
enum Color {
Brown,
Red,
Blue
}
Or even:
enum Color {
ColorBrown,
ColorRed,
ColorBlue
}
I would argue for enum Color { BrownColor };
Thoughts?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
On Wed, Oct 1, 2008 at 4:01 PM, Eric Seidel [EMAIL PROTECTED] wrote:
enum Color {
Brown,
Red,
Blue
}
I've always been a fan of this, personally... One can use Color::Brown to
solve ambiguities if necessary, but stick with just Brown in most scenarios.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Do we have any measurements of the performance benefit?
Copying verbatim Feng's post on this from the other thread into this one:
***
I did some performance measurement a few weeks ago. I made a version
of Chrome without Peerable (except SVG), it allows me to run many
tests.
I wrote a macro benchmark to exercise DOM - JS wrapping code as much
as possible:
// collect all nodes in the page
for (var j = 0; j num_nodes; j++) {
var a = nodes[j];
for (var i = 0; i 10; i++) {
a.parentNode; a.childNodes; a.firstChild; a.lastChild;
a.previousSibling; a.nextSibling; a.attributes; a.ownerDocument;
a.parentElement;
}
}
These Node properties all return a DOM node, and it loops several
times to minimize the overhead of other JS constructs.
I reused Dromaeo framework to run the test. The test page has ~4600
nodes. Using Dromaeo framework to run the test along, I observed that
with Peerable cache, it is about 7~8% faster. When the test with other
Dromaeo tests, I observed that Peerable was 25% faster, but other
tests either faster or slower, so I cannot tell if that's because of
real impact of caching or some other effects. One thing for sure is
that when running whole Dromaeo tests, the memory usage went to to
430+MB. That's may have an effect.
I think the performance difference can even be measured outside of
browser, it really measures how much performance improvement of a
cache on top of a hashmap vs. the memory overhead and maintenance
costs.
***
Again, I think the current memory cost is much higher than it needs to be,
so this tradeoff can become more favorable.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
I would argue for enum Color { BrownColor };
I believe (based on recent patch reviews) that we have undocumented
consensus that this style of first-letter-capitalized CamelCase is
preferred for enums. I tend to agree with Peter that the Color
suffix is unnecessary, but I'm not sure if there's consensus on that.
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Oct 1, 2008, at 4:48 PM, Peter Kasting wrote: On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Do we have any measurements of the performance benefit? Copying verbatim Feng's post on this from the other thread into this one: Oops, I missed that. These Node properties all return a DOM node, and it loops several times to minimize the overhead of other JS constructs. I reused Dromaeo framework to run the test. The test page has ~4600 nodes. Using Dromaeo framework to run the test along, I observed that with Peerable cache, it is about 7~8% faster. When the test with other Dromaeo tests, I observed that Peerable was 25% faster, but other tests either faster or slower, so I cannot tell if that's because of real impact of caching or some other effects. One thing for sure is that when running whole Dromaeo tests, the memory usage went to to 430+MB. That's may have an effect. Sounds promising, though I'd like to see a test that combines some mutation with pure getters. It definitely sounds like it is worth experimenting with inline wrapper pointers only for selected classes, not for all RefCounted (or even for all bindable classes). Sounds like that could give a lot of the potential speed win, without nearly as much memory cost. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 1:24 AM, David Hyatt wrote: On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. I'm with Hyatt. The reason we are having this thread is precisely to revisit the problem. Good to hear. From what you wrote, I thought you were disinterested in considering lower clamp values for setTimeout, and that is what I was referring to. (I knew you supported a high-res timer API.) From what you say below, however, I see that you are interested in lowering the clamp value. Sorry for misunderstanding. I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. That is what I was alluding to when I said it took us 3.5 years to first realize we had to add the clamp. The problems come and go, but they are consistently a problem, and it can take a while to realize it. Yup, I can totally see that happening. This is why I highlighted our architecture, which helps more squarely place blame on misbehaving sites. That should help developers and users more easily see who to blame, which should help these issues get more visibility and be resolved more quickly. I may be wrong, but I'm curious to find out. Laptops on battery power are not an issue since we wouldn't want to enable high-res timers on those systems. timeBeginPeriod(1) being too costly there. -Darin However, the bug Mike cited seems to mention problems with the 1ms limit on some real sites: http://code.google.com/p/chromium/issues/detail?id=792.http://code.google.com/p/chromium/issues/detail?id=792 At least 5 sites are mentioned, including nytimes. I think we are converging on some good solutions (somewhat lower basic clamp, new highres API) and I regret if this thread has felt hostile to anyone. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
On Wed, Oct 1, 2008 at 4:01 PM, Eric Seidel [EMAIL PROTECTED] wrote:
enum SVGStitchOptions {
SVG_STITCHTYPE_UNKNOWN = 0,
SVG_STITCHTYPE_STITCH = 1,
SVG_STITCHTYPE_NOSTITCH = 2
};
This style is usually used to stay consistent with the DOM IDLs. I don't
think we should change them in those cases as the consistency with the API
is nice.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
One can use Color::Brown to solve ambiguities if necessary
That would be invalid C++. If a given compiler accepts it then the
compiler is not strictly conforming. See the C++ Standard section 7.2
and section 9.2 p1. A scoping operator prefixed to an enumerand refers
to the enclosing scope (class or namespace).
Also, the following is invalid C++, as it introduces multiple identical
enumerands into the enclosing scope:
enum Color {
Red,
Blue
}
enum Politics{
Red,
Blue
}
Note that this above collision occurs only if the enumerations are
within the same scope, so if they are within different classes then
there isn't a problem. I personally use ColorRed, ColorBlue, etc. in
order to avoid any ambiguity for the reader of the code and to increase
clarity. It's rather like providing the scoping name that the language
doesn't strictly permit. But that's just me. But I think a sufficiently
descriptive name can make this unnecessary.
Paul
On Wed, Oct 1, 2008 at 4:01 PM, Eric Seidel [EMAIL PROTECTED]
wrote:
enum
Color {
Brown,
Red,
Blue
}
I've always been a fan of this, personally... One can use
Color::Brown to solve ambiguities if necessary, but stick with just
Brown in most scenarios.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
On Wed, Oct 1, 2008 at 5:11 PM, Paul Pedriana [EMAIL PROTECTED] wrote:
One can use Color::Brown to solve ambiguities if necessary
That would be invalid C++. If a given compiler accepts it then the compiler
is not strictly conforming. See the C++ Standard section 7.2 and section 9.2
p1. A scoping operator prefixed to an enumerand refers to the enclosing
scope (class or namespace).
You're right, my bad memory. Normally I have something like:
class MyClass {
enum Color {
Brown, Red, ...
}
};
...And in this case I was thinking of what amounts to MyClass::Brown, not
Color::Brown. But my brain elided the class out and said no, no, you can
use enum names as scopes! Bad brain. No biscuit.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 4:30 PM, Peter Kasting [EMAIL PROTECTED] wrote: On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe [EMAIL PROTECTED] wrote: Also - Chrome currently taps into RefCountable and adds Peerable across any RefCountable object, whether it needs Peerable or not. Strings are an obvious example where we don't need Peer, and there are a lot of String objects. We took this tax in Chrome because we didn't want to fork further from Webkit, and we didn't see a better way to do it. We hope to correct this soon as we reconcile differences with WebKit. I bet this weighs pretty heavily in the memory figuring below. Without hard evidence, I'd suspect that just making things Peerable only if they need to be (not even including some of Maciej, Sam, et al.'s earlier suggestions on tuning that down even further) would slash the memory numbers below pretty noticeably. I think Mads already accounted for this, so the numbers below should be pretty accurate. For each RefCountable, we can save 8 bytes if we remove Peerable. For each TreeShared we can only save 4 bytes because TreeShared already has a vtable pointer. Mike, do you know if this is before or after the effort to chop the memory impact of Peerable by reducing the inherent overhead? Seems like those 8 bytes were going to get reduced to 4 (which would save noticeably)? I think this is our current implementation; so if we can do better than 8 bytes, it would be less. Total size Potential savings www.cnn.com: 43M 410K www.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K My guess is that docs balloons so much between normal doc and big spreadsheet in large part because of the overhead of strings getting hit with this (although maybe it also creates lots more DOM nodes there). I guess the summary of all these comments from me is I strongly suspect that, if we remove the previous constraint of making as few changes as possible, we can slash these memory overhead numbers by at least 50% if not more. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
My impression from your remarks was that you thought 1ms is working fine 1ms is definitely not working fine for me. I've started reading the Washington Post since NYT makes my fan whir. Linus ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
