[webkit-dev] WKPageSetZoomFactor API
On rendering an application of size 1280X720 using webkit which is to be finally shown on 960X540 window, after resizing the page using WKPageSetZoomfactor API, layout of a div element breaks( made from three images).Is their anyway to avoid that by using some other API or Is it possible that may be i'm missing somthing in CSS Coding?. The page renders fine with separate CSS Specifications for different sizes but I have to show differently sized application on 960X540 window only. -- View this message in context: http://old.nabble.com/WKPageSetZoomFactor-API-tp33316295p33316295.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)
This plan sounds reasonable to me. No disruption of Chrome extensions in the short term, but we would better align with each other and with standards in the longer term. Jon? Regards, Maciej On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? HTML notifications are a pretty popular feature in Chrome's extension system. As of a few months ago: * 614 extensions in our web store use createHTMLNotification * 72 have more than 10k users * 14 have more than 100k users * 3 have more than 500k users * 6.7M total actextension installs We can move developers off of this API, but not overnight. Is it possible to come up with a slower deprecation plan than immediately? Since HTML notifications are already under a separate feature flag, it's probably practical to keep them around for a while, and just not include them in the proposed updated API. Do you have a suggestion for what might be a reasonable deprecation timeline? Awesome. Here is a rough plan of how deprecation could work: 0 months: Add a new extension format version and remove HTML notifications support with that version. 2 months: Support for the new format version is in Chrome's stable channel. The documentation advises the new format version, and new features require it. 4 months: We start requiring the new manifest version for new extensions uploaded to the store. 8 months: We start requiring the new manifest version for updates to existing extensions in the store. 10 months: Remove support for the old manifest version from trunk of Chrome. I believe at this point, we can remove the code from WebKit. We've never actually done this before though, so there may be some hiccups. I'd plan on about a year. We have already started a new manifest format version for Chrome 18, hopefully I can squeeze this change into that release. On Wed, Feb 8, 2012 at 9:24 PM, Adam Barth aba...@webkit.org wrote: Unrelated to timeline, it might be worthwhile to make createHTMLNotification a runtime-enabled feature so that we can avoid offering it to the web at large and possibly restrict it to only a whitelisted set of extensions. This is a very good idea. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote: Hi all, In general, the decision of whether a given feature is enabled or not is made by each port. However, at last year's W3C TPAC, there were complaints from other participants about WebKit shipping half-baked implementations and breaking feature-detection. As an example, when WebKit enabled new types for form controls, we didn't initially have useful UIs. This resulted in breaking websites that relied on feature-detection to decide whether to use new types or fallback to JS-based fallback UI. Now those websites need to rely on navigator string. (I don't intend to name-call anyone or blame this instance in particular). So when is a Web-facing feature implemented in WebKit good enough to be enabled by any port? Should there be some set of criteria to be met? I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Would other port owners find such a list useful? Is anyone else willing to help maintain it? I think a good place to keep it would be in WebKit SVN, and we should treat it as if it was shared cross-platform code, which means anything in the list would require community consensus, not port-specific decisions. In some cases, we may have a hard time coming to agreement, in which case the default should probably be no recommendation either way. For features that we recommend for all ports and that do not have port specific issues, we might even consider removing the ENABLE flag. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] test_expectations.txt for non-chromium ports
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: I think at one point Adam indicated he wanted to use them for the Apple Win port, but he is still using the Skipped files since the Win port is still using ORWT on the bots. That said, I understand why you're asking this (I think), but I would prefer that we not have to support both options indefinitely into the future. I would like to merge whatever features we need from both approaches into one solution if possible (of course, we can do that after forcing ports to use only one or the other for now). I agree that combining the features of both approach is the best long-term solution. I haven't checked with others who have an interest in the ports maintained by Apple, but I at least like different aspects of the two systems and would love to settle on a unified solution. The last time this was discussed at any length, people seemed to want expectations to cascade, but I never got any clear feedback on what the semantics of the cascade would be, and how that might interact with different modifiers in the test_expectations file. Since that time, I've come to believe that even the way Chromium uses expectations files is just making things harder for developers and maintainers, and so I would like to change how Chromium does things as well ... this is a long-winded way of saying most things are on the table for discussion. For example, we might want to use only Skipped files for tests that are always planned to be skipped, and test_expectations for things that are supposed to be temporary workarounds to keep the tree green until bugs can be filed and new baselines generated. Or, we might want to do something else ... I'd much prefer a single file, but perhaps with different status and uses of states than the current test_expectations.txt format. I do agree that distinguishing test not applicable to this port from this test is temporarily failing for unknown reasons is a good thing to do. It is unfortunate that we don't make the distinction very well right now. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] test_expectations.txt for non-chromium ports
On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: I think at one point Adam indicated he wanted to use them for the Apple Win port, but he is still using the Skipped files since the Win port is still using ORWT on the bots. That said, I understand why you're asking this (I think), but I would prefer that we not have to support both options indefinitely into the future. I would like to merge whatever features we need from both approaches into one solution if possible (of course, we can do that after forcing ports to use only one or the other for now). I agree that combining the features of both approach is the best long-term solution. I haven't checked with others who have an interest in the ports maintained by Apple, but I at least like different aspects of the two systems and would love to settle on a unified solution. Sounds good to me if there is someone willing to find consensus on a final design and actually implement it. The last time this was discussed at any length, people seemed to want expectations to cascade, but I never got any clear feedback on what the semantics of the cascade would be, and how that might interact with different modifiers in the test_expectations file. Since that time, I've come to believe that even the way Chromium uses expectations files is just making things harder for developers and maintainers, and so I would like to change how Chromium does things as well ... this is a long-winded way of saying most things are on the table for discussion. For example, we might want to use only Skipped files for tests that are always planned to be skipped, and test_expectations for things that are supposed to be temporary workarounds to keep the tree green until bugs can be filed and new baselines generated. Or, we might want to do something else ... I'd much prefer a single file, but perhaps with different status and uses of states than the current test_expectations.txt format. I think agreeing on the list of states and whether to have a single file or cascading files are the two controversial points. While (if?) we figure this out, it seems better to me if we do the simple work of only allowing either of a test_expectations.txt file or Skipped lists. Until someone does the work of unifying the two systems, it will continue to be a source of confusion to allow both for a given port. I do agree that distinguishing test not applicable to this port from this test is temporarily failing for unknown reasons is a good thing to do. It is unfortunate that we don't make the distinction very well right now. test_expectations.txt has a WONTFIX modifier for this purpose. Chromium used to have two files test_expectations.txt and test_expectations_wontfix.txt instead of having the modifier. I would kind of like us to move back to that model because then test_expectations.txt is a file that you hope to keep completely empty and test_expectations_wontfix.txt is a file that your rarely touch. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling
It's hard for me to advice you on how to optimize your website but will you be interested in creating a reduced test cases where WebKit is slow? I'm sure we can (at least try to) resolve your pain points if you can create benchmarks licensed under BSD/LGPL or WebKit performance tests (see http://trac.webkit.org/wiki/Writing%20Performance%20Tests). Best regards, Ryosuke Niwa Software Engineer Google Inc. On Sat, Feb 11, 2012 at 10:02 PM, Steven Young styoung.bi...@gmail.comwrote: [cross posting from mozilla's dev lists] I'm on the Timeline team at Facebook, which is going to be the new format for everyone's profiles real soon now. https://www.facebook.com/about/timeline We'd like to improve its browser performance, so I'd appreciate any suggestions for things we should change to speed it up. In particular, we'd like to make scrolling down through new content smoother. There are often brief (e.g. 300 ms) browser lockups, and other times there just seems to be a general feeling of heaviness. I'm going to list some of the specific issues we've identified, which we are debating how best to fix, but I'm also very interested to hear whatever anyone else thinks are the biggest perf bottlenecks. A few problems: (1) HTML / DOM size and CSS Our HTML is huge. About half of it is coming from the light blue like/comment widgets at the bottom of most stories. Within those widgets, a major portion of it is always the same. (Some of that is only needed once the user clicks into the widget, but we don't want another server round trip to fetch it.) We also have a lot of CSS rules, and applying all that CSS to all those DOM nodes gets expensive. Experimentally, removing all like/comment widgets from the page does give noticeably smoother scrolling, although it doesn't completely fix the problem. Related: We've also noticed that if you scroll very far down a content-rich timeline, and then open and close the inline photo viewer, this causes a noticeable lag, as it re-renders all existing content on the page. To fix this, we investigated dynamically removing offscreen content from the DOM and replacing it with empty divs of the same height, but we decided it wasn't worth the code complexity and fragility. (2) Repaints There are several fixed elements on the page like the blue bar at the top, the side bar, and our date navigator with the months/years. Chrome's --show-paint-rects flag showed that under most circumstances these fixed-position elements forced full-screen repaints instead of incremental repaints. The rules for what triggers a repaint vary from browser to browser, but we would ideally like to fix this everywhere. The cost of full page repaints also sometimes varies dramatically even comparing Chrome on two fairly newish Mac laptops. (3) Javascript for loading content as you scroll down We dynamically load timeline sections (e.g. a set of stories from 2009) using our BigPipe system (https://www.facebook.com/note.php?note_id=389414033919) in an iframe. In a nutshell, the HTTP response to the iframe is sent with chunked encoding, a script tag at a time. Each script tag contains some code and and HTML content that is passed up to the parent window, which requests the CSS and JS associated with that HTML content. Once the CSS is downloaded, the HTML (timeline story markup) is inserted into an offscreen DOM element. Then, once the JS is loaded, we do some fairly complicated work before we actually display the content. First, we lay out the timeline stories in an offscreen element (position:absolute; left:-px) before inserting them into the viewable page. We then have JS which checks the heights of all the stories on in the offscreen element so it can swap stories back and forth between the two columns, to keep things sorted by time going down the page. To do this, we query and cache the stories' offsetTop values all at once where possible. Probably, we could eliminate all this height-checking and column balancing if we implemented a machine learning algorithm to predict the height of each unit in advance, on the server side. Next, in an attempt to reduce user-percieved browser freezing while scrolling, our JS does not add new content in to the bottom of the main column as soon as it comes back from the server. Instead, we queue it up until the user stops scrolling and add it in then. We use document fragments where possible to insert elements. Web Inspector's profiler showed improvements when dynamically inserting many link rel=stylesheet tags in this fashion since we stopped thrashing between style recomputation and JS execution for each stylesheet, and instead just had one longer style recomputation segment. We throttle scroll/resize events so they fire every 150 ms All the while this is happening, we're potentially receiving more script tags in the iframe and doing the same thing for other pieces of content. We would
Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling
Hi Steve. Do you have a test account with a fixed content set that we can use for profiling? It's hard to speculate about performance issues without profiling, and we might get confused if we all profile different content. Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling
Profiling scrolling through my own timeline, and focusing on points where the CPU hit 100% or greater, I saw this: (1) 50% of time spent in style calculation forced by accessing element.offsetHeight in JavaScript. We then have JS which checks the heights of all the stories on in the offscreen element so it can swap stories back and forth between the two columns, to keep things sorted by time going down the page. One sometimes pernicious effect of accessing style-related properties while changing the DOM is that you force twice (or n times) the work to happen: first, style resolves to supply your property value; then, you change the DOM, and style resolves again to account for your change. Since style resolution is generally O(n), this can easily become O(n^2) behavior. According to my measurements while scrolling my own timeline, you could make scrolling twice as buttery by removing these accesses to element.offsetHeight, or doing them on a zero-delay timer after all DOM changes. (2) 50% of time spent painting images. This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote: Hi all, In general, the decision of whether a given feature is enabled or not is made by each port. However, at last year's W3C TPAC, there were complaints from other participants about WebKit shipping half-baked implementations and breaking feature-detection. As an example, when WebKit enabled new types for form controls, we didn't initially have useful UIs. This resulted in breaking websites that relied on feature-detection to decide whether to use new types or fallback to JS-based fallback UI. Now those websites need to rely on navigator string. (I don't intend to name-call anyone or blame this instance in particular). So when is a Web-facing feature implemented in WebKit good enough to be enabled by any port? Should there be some set of criteria to be met? I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Would other port owners find such a list useful? Is anyone else willing to help maintain it? I think a good place to keep it would be in WebKit SVN, and we should treat it as if it was shared cross-platform code, which means anything in the list would require community consensus, not port-specific decisions. In some cases, we may have a hard time coming to agreement, in which case the default should probably be no recommendation either way. For features that we recommend for all ports and that do not have port specific issues, we might even consider removing the ENABLE flag. One idea we've kicked around is to replace the binary on/off flags for features (e.g., in features.gypi for the Chromium port) with something like off/nightly/beta/stable. That way folks can think about whether they want to enable features for nightly, beta, or stable builds on a given port. This mechanism also gives the community a better sense for the perceived maturity of each feature. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
Related to this is the question of what ports are even on for various ports. I don't believe it's possible today to list what features are on for what ports. At least not without a lot of emailing... Before designing a finer-granularity on/off switch, it seems it might make sense to have a global view of who's using what (and ideally why?). -eric On Mon, Feb 13, 2012 at 3:13 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote: Hi all, In general, the decision of whether a given feature is enabled or not is made by each port. However, at last year's W3C TPAC, there were complaints from other participants about WebKit shipping half-baked implementations and breaking feature-detection. As an example, when WebKit enabled new types for form controls, we didn't initially have useful UIs. This resulted in breaking websites that relied on feature-detection to decide whether to use new types or fallback to JS-based fallback UI. Now those websites need to rely on navigator string. (I don't intend to name-call anyone or blame this instance in particular). So when is a Web-facing feature implemented in WebKit good enough to be enabled by any port? Should there be some set of criteria to be met? I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Would other port owners find such a list useful? Is anyone else willing to help maintain it? I think a good place to keep it would be in WebKit SVN, and we should treat it as if it was shared cross-platform code, which means anything in the list would require community consensus, not port-specific decisions. In some cases, we may have a hard time coming to agreement, in which case the default should probably be no recommendation either way. For features that we recommend for all ports and that do not have port specific issues, we might even consider removing the ENABLE flag. One idea we've kicked around is to replace the binary on/off flags for features (e.g., in features.gypi for the Chromium port) with something like off/nightly/beta/stable. That way folks can think about whether they want to enable features for nightly, beta, or stable builds on a given port. This mechanism also gives the community a better sense for the perceived maturity of each feature. Adam ___ 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] test_expectations.txt for non-chromium ports
On Feb 13, 2012, at 1:40 PM, Ojan Vafai wrote: On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: For example, we might want to use only Skipped files for tests that are always planned to be skipped, and test_expectations for things that are supposed to be temporary workarounds to keep the tree green until bugs can be filed and new baselines generated. Or, we might want to do something else ... I'd much prefer a single file, but perhaps with different status and uses of states than the current test_expectations.txt format. I think agreeing on the list of states and whether to have a single file or cascading files are the two controversial points. While (if?) we figure this out, it seems better to me if we do the simple work of only allowing either of a test_expectations.txt file or Skipped lists. Until someone does the work of unifying the two systems, it will continue to be a source of confusion to allow both for a given port. This seems like mainly an issue for ports that have both files present. If only one is actually used, then this makes it a low-stakes change. If there's any port actually applying both, then this may be a nontrivial change, and may not be worth doing until we figure out our longer-term plan. I do agree that distinguishing test not applicable to this port from this test is temporarily failing for unknown reasons is a good thing to do. It is unfortunate that we don't make the distinction very well right now. test_expectations.txt has a WONTFIX modifier for this purpose. Chromium used to have two files test_expectations.txt and test_expectations_wontfix.txt instead of having the modifier. I would kind of like us to move back to that model because then test_expectations.txt is a file that you hope to keep completely empty and test_expectations_wontfix.txt is a file that your rarely touch. It's good that there is a state for this, but WONTFIX doesn't seem like a great name to me, at least for tests that are inapplicable due to missing features. It implies both that the missing feature is by definition a bug, and also that the decision will not be reconsidered. Granted, this may be bikeshedding, but if I were, say, disabling tests for Apple's port that relate to the new WebSockets protocol because we don't have it on yet, I would be very reluctant to mark them WONTFIX. For tests that are inapplicable for reasons other than missing features, it may be simply that there is more than one acceptable behavior, in which case WONTFIX seems wrong as well. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. I personally think such a page would be a good idea. I'd love to hear input from more folks on whether this is a good idea and what the right approach is. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] test_expectations.txt for non-chromium ports
On Mon, Feb 13, 2012 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:40 PM, Ojan Vafai wrote: On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: For example, we might want to use only Skipped files for tests that are always planned to be skipped, and test_expectations for things that are supposed to be temporary workarounds to keep the tree green until bugs can be filed and new baselines generated. Or, we might want to do something else ... I'd much prefer a single file, but perhaps with different status and uses of states than the current test_expectations.txt format. I think agreeing on the list of states and whether to have a single file or cascading files are the two controversial points. While (if?) we figure this out, it seems better to me if we do the simple work of only allowing either of a test_expectations.txt file or Skipped lists. Until someone does the work of unifying the two systems, it will continue to be a source of confusion to allow both for a given port. This seems like mainly an issue for ports that have both files present. If only one is actually used, then this makes it a low-stakes change. If there's any port actually applying both, then this may be a nontrivial change, and may not be worth doing until we figure out our longer-term plan. I do agree that distinguishing test not applicable to this port from this test is temporarily failing for unknown reasons is a good thing to do. It is unfortunate that we don't make the distinction very well right now. test_expectations.txt has a WONTFIX modifier for this purpose. Chromium used to have two files test_expectations.txt and test_expectations_wontfix.txt instead of having the modifier. I would kind of like us to move back to that model because then test_expectations.txt is a file that you hope to keep completely empty and test_expectations_wontfix.txt is a file that your rarely touch. It's good that there is a state for this, but WONTFIX doesn't seem like a great name to me, at least for tests that are inapplicable due to missing features. It implies both that the missing feature is by definition a bug, and also that the decision will not be reconsidered. Granted, this may be bikeshedding, but if I were, say, disabling tests for Apple's port that relate to the new WebSockets protocol because we don't have it on yet, I would be very reluctant to mark them WONTFIX. For tests that are inapplicable for reasons other than missing features, it may be simply that there is more than one acceptable behavior, in which case WONTFIX seems wrong as well. The intention of WONTFIX is exactly that the decision likely won't need to be reconsidered (e.g. because the test is platform specific). For the other purposes (e.g. websockets), we use SKIP. I actually believe we should rename WONTFIX to NEVERFIX to make it even more clear. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit IDL cleanup
I’m really enjoying how the cleanup is going so far. The IDL attribute names are noticeably clearer and more consistent. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
(Re-sending from the right address...) I'd +1 Adam's point. It would be great if we can do something like webkit-build --gtk --stable, webkit-build --chromium --canary or webkit-build --nightly where the script read the central configuration file and find an appropriate configuration. In this way, there would be no duplication we should maintain. Even though some ports currently don't support switches through build-webkit, we can gradually switch over to the central list-based configuration settings by, for example, generating features.gypi, FeatureDefines.xcconfig or a set of flags for autoconf. Also the feature-table page could be generated from the list. We can even start from simply generating an HTML from the machine-readable configuration file, then integrate it to each build system. Although it might be overkill, I personally prefer this kind of don't repeat youself direction. -- morrita On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. I personally think such a page would be a good idea. I'd love to hear input from more folks on whether this is a good idea and what the right approach is. Cheers, 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] optimizing browser handling of Facebook Timeline scrolling
Not sure what tools you have used but you may find this helpful: http://code.google.com/webtoolkit/speedtracer/ On Sat, Feb 11, 2012 at 10:02 PM, Steven Young styoung.bi...@gmail.comwrote: [cross posting from mozilla's dev lists] I'm on the Timeline team at Facebook, which is going to be the new format for everyone's profiles real soon now. https://www.facebook.com/about/timeline We'd like to improve its browser performance, so I'd appreciate any suggestions for things we should change to speed it up. In particular, we'd like to make scrolling down through new content smoother. There are often brief (e.g. 300 ms) browser lockups, and other times there just seems to be a general feeling of heaviness. I'm going to list some of the specific issues we've identified, which we are debating how best to fix, but I'm also very interested to hear whatever anyone else thinks are the biggest perf bottlenecks. A few problems: (1) HTML / DOM size and CSS Our HTML is huge. About half of it is coming from the light blue like/comment widgets at the bottom of most stories. Within those widgets, a major portion of it is always the same. (Some of that is only needed once the user clicks into the widget, but we don't want another server round trip to fetch it.) We also have a lot of CSS rules, and applying all that CSS to all those DOM nodes gets expensive. Experimentally, removing all like/comment widgets from the page does give noticeably smoother scrolling, although it doesn't completely fix the problem. Related: We've also noticed that if you scroll very far down a content-rich timeline, and then open and close the inline photo viewer, this causes a noticeable lag, as it re-renders all existing content on the page. To fix this, we investigated dynamically removing offscreen content from the DOM and replacing it with empty divs of the same height, but we decided it wasn't worth the code complexity and fragility. (2) Repaints There are several fixed elements on the page like the blue bar at the top, the side bar, and our date navigator with the months/years. Chrome's --show-paint-rects flag showed that under most circumstances these fixed-position elements forced full-screen repaints instead of incremental repaints. The rules for what triggers a repaint vary from browser to browser, but we would ideally like to fix this everywhere. The cost of full page repaints also sometimes varies dramatically even comparing Chrome on two fairly newish Mac laptops. (3) Javascript for loading content as you scroll down We dynamically load timeline sections (e.g. a set of stories from 2009) using our BigPipe system (https://www.facebook.com/note.php?note_id=389414033919) in an iframe. In a nutshell, the HTTP response to the iframe is sent with chunked encoding, a script tag at a time. Each script tag contains some code and and HTML content that is passed up to the parent window, which requests the CSS and JS associated with that HTML content. Once the CSS is downloaded, the HTML (timeline story markup) is inserted into an offscreen DOM element. Then, once the JS is loaded, we do some fairly complicated work before we actually display the content. First, we lay out the timeline stories in an offscreen element (position:absolute; left:-px) before inserting them into the viewable page. We then have JS which checks the heights of all the stories on in the offscreen element so it can swap stories back and forth between the two columns, to keep things sorted by time going down the page. To do this, we query and cache the stories' offsetTop values all at once where possible. Probably, we could eliminate all this height-checking and column balancing if we implemented a machine learning algorithm to predict the height of each unit in advance, on the server side. Next, in an attempt to reduce user-percieved browser freezing while scrolling, our JS does not add new content in to the bottom of the main column as soon as it comes back from the server. Instead, we queue it up until the user stops scrolling and add it in then. We use document fragments where possible to insert elements. Web Inspector's profiler showed improvements when dynamically inserting many link rel=stylesheet tags in this fashion since we stopped thrashing between style recomputation and JS execution for each stylesheet, and instead just had one longer style recomputation segment. We throttle scroll/resize events so they fire every 150 ms All the while this is happening, we're potentially receiving more script tags in the iframe and doing the same thing for other pieces of content. We would love any pointers you guys have. Thanks, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list
Re: [webkit-dev] Web Notifications API
Hi! Lots of responses below (mashed previous replies together for topic coherency): John Gregg wrote: Which missing aspects of the Feature permissions spec are you concerned about? I was only referring to the fact that the spec calls for a separate generic interface for permissions with a parameter that identifies the feature [FeaturePermissions.permissionLevel(notifications)], and in this case it would still be attached to the Notifications interface [Notifications.permissionLevel()]. At the risk of derailing the discussion, I have some concerns about the nature of that spec. Although from an engineering standpoint one could argue for a generic interface, I see two issues. 1) It makes a low-barrier entry to tack on features that require permissions. And 2) it could permit UAs to couple features in a nag sheet, making for a bad user experience. I think it makes sense to keep the permissions mechanism confined to the needs of notifications. Andrew Wilson wrote: One note: if we're going to change the API at all, I'd like to see us change it exactly once - to the draft API defined by the standards body. So I'd be opposed to a transitional phase window.webkitNotifications - WebKitNotification() - draft standard. Otherwise, applications using this API have to try to support all 3 APIs to deal with legacy browsers. I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. John Gregg wrote: Overall my opinion on replaceId is that it's quite useful practically, and we already have real world examples of that usefulness. As a real-world example, gmail wants to show two different types of notifications: chat and email. So it uses two replace IDs: _chat_userid and _email_userid. This ensures that only a single chat notification and a single email notification ever appear for a given user. Ok, thanks for explaining the reason behind this, and it makes total sense. I agree about the utility of having some kind of ID to coordinate between multiple pages, but I think replaceId might be the wrong name here? Maybe just id or globalID? I think it also gives platforms an opportunity to determine how they want to handle dupe notifications (as you said, ignore or replace). Andrew Wilson wrote: Nit: Can you clarify what default means? I think it means the user has not granted permission yet, but you can still create notifications and they will be queued until such time that the user chooses to grant permission. Maybe something clearer than default, like not-granted (the reason why default concerns me is a UA may decide to provide notification permission to all origins as the default configuration, but it seems like this would not map to default but rather to granted. I understand your concern about ambiguity, but I think your suggestion implies that a default of the opposite policy exists or could exist. And yes, I think any UA that wishes to grant permission by default should just return granted. From a flow perspective, it makes sense for a UA to deny by default, for any web site to detect that it's denied, and then request the UA for permission. Assuming the UA's default policy is the opposite, I don't think the flow fits. That is, assume a UA allows all notifications by default, and the web site detects a default-allowed policy. Do you believe all websites will then ask the user to deny itself the privilege? I think in this scenario, the UA should prompt the user for denial directly, and not assume that the web site will be a good citizen and handle the default-granted case. Therefore, I think UA's that want to give permission by default should just return granted. Instead of using passive granted, denied, and default, how about yes, no, and ask? It's more colloquial, but easier to read, and more actionable. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either granted or denied). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not invoke the callback). Any notifications posted in the meantime would be queued until then. Multiple calls to this function should just result in one visible request. Just a note, since I'm not sure what immediately means - the callback should always be invoked asynchronously even if permissions have already been granted/denied. I was thinking that in the case where the user already decided, that the callback would be done
Re: [webkit-dev] Web Notifications API
On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Notifications API
On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Google Calendar fwiw ( http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/ ) Adam ___ 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] Web Notifications API
On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: Hi! Lots of responses below (mashed previous replies together for topic coherency): John Gregg wrote: Which missing aspects of the Feature permissions spec are you concerned about? I was only referring to the fact that the spec calls for a separate generic interface for permissions with a parameter that identifies the feature [FeaturePermissions.permissionLevel(notifications)], and in this case it would still be attached to the Notifications interface [Notifications.permissionLevel()]. At the risk of derailing the discussion, I have some concerns about the nature of that spec. Although from an engineering standpoint one could argue for a generic interface, I see two issues. 1) It makes a low-barrier entry to tack on features that require permissions. And 2) it could permit UAs to couple features in a nag sheet, making for a bad user experience. I think it makes sense to keep the permissions mechanism confined to the needs of notifications. Andrew Wilson wrote: One note: if we're going to change the API at all, I'd like to see us change it exactly once - to the draft API defined by the standards body. So I'd be opposed to a transitional phase window.webkitNotifications - WebKitNotification() - draft standard. Otherwise, applications using this API have to try to support all 3 APIs to deal with legacy browsers. I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. I don't have an answer for you here, as the internet is vast :) Among google properties, Gmail and Google Calendar currently use it. I'm not aware of any other google property that uses it in their web pages, but some do via extensions. John Gregg wrote: Overall my opinion on replaceId is that it's quite useful practically, and we already have real world examples of that usefulness. As a real-world example, gmail wants to show two different types of notifications: chat and email. So it uses two replace IDs: _chat_userid and _email_userid. This ensures that only a single chat notification and a single email notification ever appear for a given user. Ok, thanks for explaining the reason behind this, and it makes total sense. I agree about the utility of having some kind of ID to coordinate between multiple pages, but I think replaceId might be the wrong name here? Maybe just id or globalID? I think it also gives platforms an opportunity to determine how they want to handle dupe notifications (as you said, ignore or replace). Andrew Wilson wrote: Nit: Can you clarify what default means? I think it means the user has not granted permission yet, but you can still create notifications and they will be queued until such time that the user chooses to grant permission. Maybe something clearer than default, like not-granted (the reason why default concerns me is a UA may decide to provide notification permission to all origins as the default configuration, but it seems like this would not map to default but rather to granted. I understand your concern about ambiguity, but I think your suggestion implies that a default of the opposite policy exists or could exist. And yes, I think any UA that wishes to grant permission by default should just return granted. From a flow perspective, it makes sense for a UA to deny by default, for any web site to detect that it's denied, and then request the UA for permission. Assuming the UA's default policy is the opposite, I don't think the flow fits. That is, assume a UA allows all notifications by default, and the web site detects a default-allowed policy. Do you believe all websites will then ask the user to deny itself the privilege? I think in this scenario, the UA should prompt the user for denial directly, and not assume that the web site will be a good citizen and handle the default-granted case. Therefore, I think UA's that want to give permission by default should just return granted. Instead of using passive granted, denied, and default, how about yes, no, and ask? It's more colloquial, but easier to read, and more actionable. OK, I think we're on the same page here. I don't have a strong opinion one way or the other regarding the naming of these permission values. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either granted or denied). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not
Re: [webkit-dev] Web Notifications API
On Mon, Feb 13, 2012 at 5:31 PM, David Levin le...@chromium.org wrote: On Mon, Feb 13, 2012 at 5:29 PM, Adam Barth aba...@webkit.org wrote: On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. IRCCloud is an example of a site that I use every day that uses notifications. Google Calendar fwiw (http://www.howtogeek.com/howto/28573/how-to-enable-desktop-notifications-for-google-calendar-in-chrome/) They're also used by the New York Times skimmer view as well as TweetDeck. (These are just web sites I happened to use personally, not any sort of exhaustive list.) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
I think we're talking about a couple of different things now: 1) Table of what the WebKit community as a whole (instead of individual point maintainers) thinks should be enabled in stable releases. This would be input to port maintainers looking to make a release. 2) Documenting what enable flags are actually on for given ports as shipped. Probably hard to gather this info, but might be useful input for the WebKit community. 3) Changing build systems to enable compiling nightly and stable versions from the same tree, so both modes are documented in trunk. Requires some coding for various build systems. I like (2) and (3), but I don't think they replace the usefulness of (1). I think the mention of the feature-table page is blending (2) and (1), which would serve different purposes. Regards, Maciej On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: (Re-sending from the right address...) I'd +1 Adam's point. It would be great if we can do something like webkit-build --gtk --stable, webkit-build --chromium --canary or webkit-build --nightly where the script read the central configuration file and find an appropriate configuration. In this way, there would be no duplication we should maintain. Even though some ports currently don't support switches through build-webkit, we can gradually switch over to the central list-based configuration settings by, for example, generating features.gypi, FeatureDefines.xcconfig or a set of flags for autoconf. Also the feature-table page could be generated from the list. We can even start from simply generating an HTML from the machine-readable configuration file, then integrate it to each build system. Although it might be overkill, I personally prefer this kind of don't repeat youself direction. -- morrita On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. I personally think such a page would be a good idea. I'd love to hear input from more folks on whether this is a good idea and what the right approach is. Cheers, 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] optimizing browser handling of Facebook Timeline scrolling
will you be interested in creating a reduced test cases where WebKit is slow? Ryosuke - For now, user complaints about slowness are too unpredictable and poorly defined for me to create a simple test case. I will report back here if we reach that point. (1) 50% of time spent in style calculation forced by accessing element.offsetHeight in JavaScript. Geoff - I am going to bite the bullet and rip this logic out. We are pushing too much complexity into the browser. (2) 50% of time spent painting images... This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Geoff - Painting images specifically, or just repainting the page in general? Not sure what tools you have used but you may find this helpful: http://code.google.com/webtoolkit/speedtracer/ David - Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
On Tue, Feb 14, 2012 at 11:09 AM, Maciej Stachowiak m...@apple.com wrote: I think we're talking about a couple of different things now: 1) Table of what the WebKit community as a whole (instead of individual point maintainers) thinks should be enabled in stable releases. This would be input to port maintainers looking to make a release. 2) Documenting what enable flags are actually on for given ports as shipped. Probably hard to gather this info, but might be useful input for the WebKit community. 3) Changing build systems to enable compiling nightly and stable versions from the same tree, so both modes are documented in trunk. Requires some coding for various build systems. I like (2) and (3), but I don't think they replace the usefulness of (1). I think the mention of the feature-table page is blending (2) and (1), which would serve different purposes. You are right. And talking about (1) is fine for this discussion to be focused. I went off the point. Regards, -- morrita Regards, Maciej On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: (Re-sending from the right address...) I'd +1 Adam's point. It would be great if we can do something like webkit-build --gtk --stable, webkit-build --chromium --canary or webkit-build --nightly where the script read the central configuration file and find an appropriate configuration. In this way, there would be no duplication we should maintain. Even though some ports currently don't support switches through build-webkit, we can gradually switch over to the central list-based configuration settings by, for example, generating features.gypi, FeatureDefines.xcconfig or a set of flags for autoconf. Also the feature-table page could be generated from the list. We can even start from simply generating an HTML from the machine-readable configuration file, then integrate it to each build system. Although it might be overkill, I personally prefer this kind of don't repeat youself direction. -- morrita On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. I personally think such a page would be a good idea. I'd love to hear input from more folks on whether this is a good idea and what the right approach is. Cheers, 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] optimizing browser handling of Facebook Timeline scrolling
(1) 50% of time spent in style calculation forced by accessing element.offsetHeight in JavaScript. Geoff - I am going to bite the bullet and rip this logic out. We are pushing too much complexity into the browser. Bear in mind that I didn't do enough analysis to explain why the .offsetHeight code was so costly. It may be possible to tune this code and keep it in the browser. For example, you could maintain a separate document for measuring items, so you could measure without reflowing the main document. (2) 50% of time spent painting images... This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Geoff - Painting images specifically, or just repainting the page in general? Painting images specifically. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
