Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute
On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson wrote: > I'm not sure I like this proposal. Why is canvas special? Why doesn't > 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 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 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 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 >> 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 , 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 1:25 PM, Ryosuke Niwa wrote: > On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens wrote: > >> On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote: >> >>> On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote: >>> >>> On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser >>> wrote: >>> >>>> 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] window.internals abuse
On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote: > On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote: > > On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser wrote: > >> 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 12:42 PM, Simon Fraser wrote: > 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] css: rotateY(90) with perspective()
+shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski wrote: > 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 wrote: > 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 wrote: > On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov 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=172046&action=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 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 > 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 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 >>> 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 wrote: > On Fri, Jul 13, 2012 at 5:57 AM, Stephen Chenney wrote: > >> 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 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" 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 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 >> > Date: Thursday, July 12, 2012 7:39 PM >> > To: Adam Barth , Andrei Bucur >> > >> > Cc: "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 >> > To: Andrei Bucur >> > Cc: "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 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 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 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 wrote: > >> 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 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] handling failing tests (test_expectations, Skipped files, etc.)
On Mon, Apr 9, 2012 at 5:42 PM, Dirk Pranke wrote: > 3) Don't use test_expectations.txt to suppress failures across a > single cycle of the bot, just so you can gather updated baselines > without the tree going red. While it might seem that you're doing tree > maintainers a favor, in my experience this just makes things confusing > and it's better to let the tree go red until you can actually > rebaseline things. It's too easy to add a suppression "for now" and > then forget about it. > IIUC, this is not possible if you are landing the change with the commit queue, as it will see the failing tests and CQ-? Also, I've been told explicitly by reviewers to mark the test fails with a bug filed against it, rather than commit something that breaks the tree. Would you see this as acceptable behaviour given the bug filed against it and in a comment in test_expectations? ___ 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 wrote: > On Mar 16, 2012, at 9:26 AM, Ryosuke Niwa 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 wrote: > On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik 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 > > 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 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=get&search=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
