Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson d...@apple.com wrote: I'm not sure I like this proposal. Why is canvas special? Why doesn't img get an opaque attribute (or flag)? Why not every element? There is ongoing work to infer opaqueness in every other kind of element when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634 I don't think the performance benefit, which is mostly going to be on very limited hardware, is worth changing the rendering model that is consistent across every other part of the Web. Dean On 15/03/2013, at 4:53 AM, Stephen White senorbla...@chromium.org wrote: Hi Dirk, There have been at least five options considered, with contributions from Chromium, Adobe and Mozilla so far. The moz-opaque idea was first floated by Robert O'Callahan from Mozilla, and Ian Hickson offered to spec it if another browser vendor wanted to implement it. I took him up on that offer, and have made my humble effort to massage it into a concrete proposal in the linked message above. After proposing it here, the alternative suggestion is to sync it up with the WebGL syntax, and use a context creation object at getContext() time rather than an attribute on the canvas element. I have no strong feelings about this either way, and I'm working on a patch to try out the WebGL approach (I already have a WebKit patch which implements the platform-independent parts of the opaque attribute approach). However, if we do go that way, I'd prefer not to make this proposal conditional on changes to the WebGL spec, concerns which I've outlined over on what-wg. Stephen On Wed, Mar 13, 2013 at 12:30 PM, Dirk Schulze dschu...@adobe.com wrote: This is a very long thread and I did not see any conclusions or agreement on this thread. Can you summarize the topic and the status on the acceptance level please? Greetings, Dirk On Mar 13, 2013, at 9:15 AM, Stephen White senorbla...@chromium.org wrote: Hi WebKittens, I'm planning to implement the canvas opaque attribute, as proposed here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html . This is an attribute that causes the allocation of an opaque backing store for canvas, allowing optimizations at the time the canvas is composited into the page, such as disabling blending and culling obscured content. It is based on the moz-opaque attribute currently shipping in Firefox. I'll be placing the feature behind the build-time flag ENABLE(OPAQUE_CANVAS). Let me know if you have any comments or concerns. Stephen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. - dana ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? It can be enabled by UI code via the platform layer directly. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens dan...@chromium.orgwrote: On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? It can be enabled by UI code via the platform layer directly. That sounds like a feature to be tested via testRunner object, not internals object. internals object should be reserved for testing cross-platform, cross-port features. Otherwise, we'll end up zillion of if-defs for each and every port specific feature we want to test :( I don't think that testRunner existed in its current form a year ago when this was written. I can look into moving it there if it would be better suited. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] css: rotateY(90) with perspective()
+shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote: Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Fri, Jan 4, 2013 at 12:15 AM, Simon Fraser simon.fra...@apple.comwrote: On Jan 3, 2013, at 7:43 PM, Steve Block wrote: Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I find point - point = size quite useful in general, and it seems to make logical sense. Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? In chromium we recently added such a class with the name Vector2d, to differentiate it from std::vector. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? If you want to see how this is done in Chromium, you might want to study the --device-pixel-ratio command line flag. In general, I don't think you want to try to implementing this feature by hacking WebCore as it requires coordination beyond WebCore to do correctly. I think Adam is refering to the --force-device-scale-factor=2 flag for chromium. To try it out, you may need to build with the use_ash=1 flag. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Some stderr output missing when using run-webkit-tests
On Mon, Oct 29, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: If that's the case, it's a bug, and new to me. The output was present on the results page, but it would only include the first, maybe, 60 lines or so. - Dana -- Dirk On Mon, Oct 29, 2012 at 3:42 PM, Terry Anderson tdander...@chromium.org wrote: I was actually noticing that some of the stderr output was missing from a failing test, not a passing one. Terry On Sun, Oct 28, 2012 at 8:42 PM, Dirk Pranke dpra...@chromium.org wrote: As Balazs said, we don't save the stderr output from tests that pass. So, you don't have to crash, but your tests have to at least fail. It wouldn't be hard to change that somehow ... -- Dirk On Sun, Oct 28, 2012 at 4:29 PM, Terry Anderson tdander...@chromium.org wrote: Hi webkit-dev, When I include fprintf(stderr, ...) statements in WebKit code that I expect to be executed when running a set of layout tests, the summary page of run-webkit-tests will sometimes only show a subset of these statements. However, when I add a CRASH() somewhere in the code, the missing stderr output will appear on the summary page. Has anyone else experienced this issue? Is there a way to force run-webkit-tests to display all stderr output without needing to force a crash at a particular point in the code? Terry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Hashing pairs in WTF
Hello WebKittens, I noticed the other day that our hashing method in wtf/HashFunctions.h for hashing of pairs can be improved. We have a hash method (WTF::intHash) for a single integer that takes 32 bits as input and produces a key of 32 bits. This works well enough for hashing an integer, as it is a reversible function. To hash a pair (A, B) of 32 bits, we hash each of A and B with the above method, to produce (A', B'). Then concatenate the two and hash the result to produce a 64 bit hash code. This whole process is reversible. However, as a final step we truncate the hash code to 32 bits, which destroys the properties of the hashing method. The result is a hash function that collides more than it should for typical inputs. I am proposing a patch [1] to improve the hash method for keys composed of pairs. The new method [2][3][4] is both almost-universal and efficient for machines to compute. To demonstrate the difference I inserted pairs of integers into a WTF::HashMap. A good hash method will populate the HashMap more densely. Whereas a bad hash method does not and will cause the HashMap to require more space and more calls to realloc(), which is a costly function and will be slower in the end. In testing, the new hash method reduced the time to insert integer pair keys into a WTF::HashMap by between 23% and 49% for different sized input sets. For example, with various input set sizes, the time to insert into the WTF::HashMap, across multiple runs, was reduced by: 8192 elements: 32% 31% 30% 34% 34% 33% 4096 elements: 47% 48% 48% 47% 47% 49% 1024 elements: 43% 43% 39% 42% 35% 256 elements: 25% 39% 33% 41% 23% Lookup times into an empty HashMap were also improved, incidentally. For example, with the old intHash method, making 8192 queries requires approximately 129ms on my machine while the new method takes less than 1ms. All testing was done on a 64-bit x86 machine. The tests I ran are attached to the bug [1] for those who may be interested in repeating the experiment [5]. I want to repeat that the reason the new hash method is faster is because of better hashing behaviour - ie, fewer collisions and a denser resulting hash table. I am not comparing the time to do the hash() itself. Any feedback would be welcome on the bug! Thanks, Dana [1] https://bugs.webkit.org/show_bug.cgi?id=96022 [2] http://opendatastructures.org/versions/edition-0.1d/ods-java/node33.html#SECTION00832000 [3] http://pages.cpsc.ucalgary.ca/~woelfel/paper/efficient_strongly/efficient_strongly.pdf [4] http://pages.cpsc.ucalgary.ca/~woelfel/paper/diss/diss.pdf [5] https://bugs.webkit.org/attachment.cgi?id=162804 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)
On Fri, Jul 13, 2012 at 1:56 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jul 13, 2012 at 5:57 AM, Stephen Chenney schen...@chromium.orgwrote: I don't doubt there are poor comments, both outdated and useless. That's a reviewing failure. You have simply highlighted the fact that any standard for comments requires reviewer attention. Hence cost of maintaining comments. I don't know how to review a patch and make sure all relevant comments are updated. As I have illustrated before, you can be modifying a function X, then a completely random function A which calls B that in turn calls C that in turns D ... that in turn calls X may have a comment dependent on the previous behavior of X without ever mentioning X. How am I supposed to know that there is such a comment? How is that different than the same question but replace comment with behaviour? In both cases A is no longer doing what it expected. Something is going to break, and A will have to be fixed/updated, comment included. - Dana ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll also suggest we rename the existing Region class now that the term region has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? IntRegion? It seems closer to an IntRect than a LayoutRect. - Ryosuke On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote: I would go with CSSRegion, and stick it in the css/ folder. Much of the CSS folder is our implementation of the CSS Object Model (CSSOM). At some point it might make sense to pull all the classes which implement the CSSOM out of css/ into a new cssom/ similar to dom/, but that's a later discussion. -eric On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur abu...@adobe.com wrote: From my knowledge the CSS prefix is reserved for the CSS engine classes in WebKit. Prefixing the Region class with CSS could prove confusing. Regards, Andrei. From: Alan Stearns stea...@adobe.com Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.org To: Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please include function-level comments in change log entries
On Fri, Jul 6, 2012 at 1:05 PM, Dan Bernstein m...@apple.com wrote: It appears that lately most WebCore change log entires don’t include any comments on individual functions. An overall description of the change at the top of the change log entry is valuable, but it is no substitute for describing the changes to each function. Good function-level comments are useful both while reviewing a patch and while revisiting existing code. Personally, I find that writing the function-level comments helps me a lot in reviewing my own patches before I post them. I find that the overhead of maintaining comments outside of the top of the changelog is excessive. Every time I change a patch in a non-trivial way during the review process, I must regenerate the changelogs. Copy/paste/edit the description at the top is not unreasonable. Hand-merging my old changelog with the new one for each method becomes an egregious amount of work. And I don't see how it helps review more than a proper description at the top that mentions the methods of interest as appropriate. Thanks. ___ 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] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
I agree, having this in Settings seems to imply that the browser's physical device remains the same for its entire lifetime which is not true. - Dana On Thu, May 31, 2012 at 6:52 PM, James Robinson jam...@google.com wrote: (top-posting to fit in) Doesn't the same argument apply to *deviceScaleFactor? That doesn't make sense as a Setting either. Pushing one or both out of settings doesn't answer the question of whether they are redundant. My gut feeling is that they are and we should fold them together. Alternately, delete defaultDeviceScaleFactor completely. - James On Thu, May 31, 2012 at 3:50 PM, Simon Fraser simon.fra...@apple.comwrote: I don' t think devicePixelRatio() belongs in settings. It should be either be obtained from the platform code in WebCore/WebKit, or pushed in via API. Simon On May 31, 2012, at 3:48 PM, Adam Barth wrote: Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Device and page scaling
On Tue, May 29, 2012 at 9:54 PM, Adam Barth aba...@webkit.org wrote: There's a lot of confusion in the code base about how page and device scaling works. Different ports are using Page::deviceScaleFactor for incompatible purposes. On Mac, Page::deviceScaleFactor represents the actual scaling factor of the physical device. It can change over time because a given Page might be displayed on different devices over its lifetime (e.g., if there are multiple monitors). On Chromium and Qt, Page::deviceScaleFactor starts off as the actual scaling factor of the physical device, but it can change over time if a web page has a viewport meta tag that contains a target-densitydpi directive. There's also Settings::defaultDeviceScaleFactor, which represents the actual scaling factor of the physical device on ports that adjust Page::deviceScaleFactor based on the target-densitydpi directive. Settings::defaultDeviceScaleFactor does not work on Mac (and can't work because of multimon). Here's a proposal for making sense out of this mess: == Page::pageScaleFactor == Page::pageScaleFactor is a scaling factor that arises from the meta viewport tag and from pinch-to-zoom interactions. This proposal doesn't change anything about page scaling. == Page::deviceScaleFactor == Page::deviceScaleFactor is the scaling factor of the actual physical device. It's value changes when the physical device displaying the Page changes its scaling factor. It is not affected by target-densitydpi or anything else unrelated to the physical device. == Page::effectiveDeviceScaleFactor == Page::effectiveDeviceScaleFactor starts off as matching Page::deviceScaleFactor but changes to reflect any target-densitydpi directives. It's unclear to me how Page::effectiveDeviceScaleFactor should react when the underlying physical device changes its scaling factor. Currently, that shouldn't occur, so I'm inclined to add an ASSERT and worry about it later. == Settings::defaultDeviceScaleFactor == This variable will be deleted. Thoughts? Thanks for starting this discussion. The other difference between ports or platforms is how deviceScaleFactor is applied. It can be applied by being multiplied into pageScaleFactor, or it could be applied separately as a post-processing/compositing property, or potentially other ways. Did you have thoughts on that? You say pageScaleFactor is unchanged, but I think it would be nice to separate these two things more distinctly, then combine them more explicitly where appropriate. - Dana ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
On Fri, Mar 16, 2012 at 12:54 PM, William Siegrist wsiegr...@apple.comwrote: On Mar 16, 2012, at 9:26 AM, Ryosuke Niwa rn...@webkit.org wrote: As I stated on this thread, I was getting reasonable download speed from svn and others at home (Comcast business in SF). You may want to compare my traceroute to others and see if there's a difference. I have been comparing them and do not see a pattern. I've gotten reports of people both near and far having both fast and slow downloads, and the problem has been reported against more than 1 service and more than 1 piece of hardware. I've found the problem to be intermittent. I'm typically pulling about 5-10 kB/s, but occasionally/rarely pull over 1MB/s. I had at first assumed it was load on the server causing the problem, because you can tell it's going to be a slow one when you get 75% through the compressing objects stage of a git fetch, which is all on the server AIUI, and it starts to crawl already. - Dana ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 12:35 PM, Alexis Menard alexis.men...@openbossa.orgwrote: On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? http://progit.org/book/ch7-4.html Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ 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
