[webkit-dev] Regd. Hardware Rendering
Hello, Webkit has two rendering path, software rendering and hardware rendering. When hardware rendering is enabled, it takes the hardware rendering path. I would like to go through the code in the WebCore where it takes the decision to go to either one of the path. As I am very new in using webkit, I don't have much idea. Hence it would be very helpful, if someone can tell me which source files I need to look for this information. Thanks in advance. Regards, Debojyoti Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Regd. Hardware Rendering
You should start following the accelerated_compositing macro Also reading these might help http://dev.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome http://qtwebkit.blogspot.in/2010/10/texture-mapper-accelerated-compositing.html http://trac.webkit.org/wiki/Accelerated%20Compositing -- Sriram On Thursday, May 24, 2012, wrote: Hello, Webkit has two rendering path, software rendering and hardware rendering. When hardware rendering is enabled, it takes the hardware rendering path. I would like to go through the code in the WebCore where it takes the decision to go to either one of the path. As I am very new in using webkit, I don’t have much idea. Hence it would be very helpful, if someone can tell me which source files I need to look for this information. Thanks in advance. *Regards,* *Debojyoti* * Please do not print this email unless it is absolutely necessary. * The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Sriram Neelakandan Author - Embedded Linux System Design And Development ( http://tinyurl.com/2doosu) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feature announcement: Font Boosting
I think it would be great to talk about this at the WebKit summit tomorrow, if you are there. Unfortunately I wasn't able to make the WebKit summit, but beverloo mentioned that you were able to chat a little. I'm happy to discuss further by email or otherwise :) For those who aren't following the bug, I've uploaded the full diff[1] of Chrome for Android's current Font Boosting implementation (not for review, just for reference to show how it fits together). And I've uploaded the first actual patch (adding compile/runtime flags) to webkit.org/b/87394, which is now up for review. Cheers, John [1]: http://webkit.org/b/FontBoosting On Thu, Apr 19, 2012 at 2:02 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I think it would be great to talk about this at the WebKit summit tomorrow, if you are there. Cheers Kenneth On Tue, Apr 17, 2012 at 10:17 PM, John Mellor joh...@chromium.org wrote: Hi webkit-dev, You may have heard http://youtu.be/aCdZIHBbRV0?t=1m26s that Chrome for Android includes a Font Boosting feature. This is similar in intent to the text size adjusthttp://developer.apple.com/library/ios/DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html#//apple_ref/doc/uid/TP40006510-SW16feature in Mobile Safari, that the QT port also seems interested in http://webkit.org/b/73546. Other mobile browsers have corresponding features: Mobile Firefox uses font inflationhttp://dbaron.org/log/2026-font-inflationand IE Mobile applies text size adjustmenthttp://msdn.microsoft.com/en-us/library/ff462082(v=vs.92).aspx#sectionToggle2 . Font Boosting increases the font size in wide blocks, so that you can easily read the text after double-tapping to fit the block to the screen, instead of having to zoom in further then scroll from side to side for each line you read. The details are subtle (since web text layout is complicated), and there's still a lot of tweaking to do. We chose to boost font sizes more than Mobile Safari (which has various limits), producing easily legible text, more in line with IE Mobile and Firefox Mobile. This is core functionality for mobile browsers, so we would like to upstream our implementation of Font Boosting to WebCore. We are keen to share code with other ports (e.g. QT and Mobile Safari) that are interested in this feature, and will be happy to incorporate suggestions on how to make this easier. I've opened webkit.org/b/84186 to track this effort. Best wishes, John -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
Do you just need to force a layout at the end of repaintTest, e.g. document.body.offsetHeight;? On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote: Hello WebKittens, I'm trying to simplify the patch for a certain repaint bug ( https://bugs.webkit.org/show_bug.cgi?id=59863 ) by using ref tests instead of pixel tests. The test HTML file should first render the document in state 1 and then, by modifying the DOM, render it again state 2. The bug appears when repainting from state 1 to state 2. The expected result HTML for the test is just a document directly written in state 2 (so there is no transition, no bug). This should work on all the platforms but there's problem with the time control between paints for state 1 and state 2 in the test HTML. I've tried three options: 1. Use setTimeout() to update the DOM - I really wouldn't like to use this because it slows down the test and can be flaky. 2. Use layoutTestController.display() before modifying the DOM to trigger a paint - calling this seems to make the test fail because display() starts tracking the paint rects which doesn't happen in the reference document. 3. Make use of requestAnimationFrame to time the paintings for state 1 and state 2 - doesn't work directly out-of-the-box because requestAnimationFrame schedules a full repaint after going into state 2 and the bug doesn't reproduce anymore. Is there a preferred solution to this problem or another one that I'm missing? Thanks, Andrei. ___ 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] Using ref tests for repaint bugs
No, I need a way to force a paint operation, similar to what layoutTestController.display() achieves, but without tracking the paint rectangles. Does anyone you find value in adding an optional parameter to display (or create another method on LTC) that disables paint rectangle tracking. The main advantage for such a change would be in extending the ref tests power to also cover repaint tests (at least a part of them), thus making pixel tests less necessary. Repaint bugs appear usually when the layout changes but the old pixels are incorrectly invalidated. By making the reference HTML directly identical to the test document after the bug triggering changes have been applied, it is pretty certain that the output pixels for the reference file will not contain the repaint artifacts (there's no repaint operation involved). When running such a test with a client that has the bug, it will fail because the test file output will have artifacts and the reference output will not. On the other hand, using a client with the repaint bug fixed, the pixels output for the test and reference files should be identical. Thoughts? Andrei. On Thu, May 24, 2012 at 11:57 PM, Ojan Vafai o...@chromium.org wrote: Do you just need to force a layout at the end of repaintTest, e.g. document.body.offsetHeight;? On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote: Hello WebKittens, I'm trying to simplify the patch for a certain repaint bug ( https://bugs.webkit.org/show_bug.cgi?id=59863 ) by using ref tests instead of pixel tests. The test HTML file should first render the document in state 1 and then, by modifying the DOM, render it again state 2. The bug appears when repainting from state 1 to state 2. The expected result HTML for the test is just a document directly written in state 2 (so there is no transition, no bug). This should work on all the platforms but there's problem with the time control between paints for state 1 and state 2 in the test HTML. I've tried three options: 1. Use setTimeout() to update the DOM - I really wouldn't like to use this because it slows down the test and can be flaky. 2. Use layoutTestController.display() before modifying the DOM to trigger a paint - calling this seems to make the test fail because display() starts tracking the paint rects which doesn't happen in the reference document. 3. Make use of requestAnimationFrame to time the paintings for state 1 and state 2 - doesn't work directly out-of-the-box because requestAnimationFrame schedules a full repaint after going into state 2 and the bug doesn't reproduce anymore. Is there a preferred solution to this problem or another one that I'm missing? Thanks, Andrei. ___ 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] Using ref tests for repaint bugs
On Thu, May 24, 2012 at 3:59 PM, Andrei Bucur andrei.bu...@gmail.comwrote: No, I need a way to force a paint operation, similar to what layoutTestController.display() achieves, but without tracking the paint rectangles. Does anyone you find value in adding an optional parameter to display (or create another method on LTC) that disables paint rectangle tracking. I don't see any problems with this. Someone more familiar with the paint code might see issues. The main advantage for such a change would be in extending the ref tests power to also cover repaint tests (at least a part of them), thus making pixel tests less necessary. Repaint bugs appear usually when the layout changes but the old pixels are incorrectly invalidated. By making the reference HTML directly identical to the test document after the bug triggering changes have been applied, it is pretty certain that the output pixels for the reference file will not contain the repaint artifacts (there's no repaint operation involved). When running such a test with a client that has the bug, it will fail because the test file output will have artifacts and the reference output will not. On the other hand, using a client with the repaint bug fixed, the pixels output for the test and reference files should be identical. Thoughts? I'm open to experimenting with this, but different ports have very different repaint schemes (e.g. Chromium merges all the repaint rects into a large rect). I'm curious how likely a repaint reftest is to work across ports. If you're willing to investigate converting a handful of repaint tests over to reftests, that'd be very helpful. FWIW, you can easily test the reftests on the chromium port by sending a patch to the EWS via bugzilla since the Chromium-linux EWS runs the layout tests. Obviously, if we can convert repaint tests reftests (or, at least have new repaints tests be reftests), that would be a huge improvement in maintainability since repaint tests are one of the few categories of tests where we can't currently use reftests. Andrei. On Thu, May 24, 2012 at 11:57 PM, Ojan Vafai o...@chromium.org wrote: Do you just need to force a layout at the end of repaintTest, e.g. document.body.offsetHeight;? On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote: Hello WebKittens, I'm trying to simplify the patch for a certain repaint bug ( https://bugs.webkit.org/show_bug.cgi?id=59863 ) by using ref tests instead of pixel tests. The test HTML file should first render the document in state 1 and then, by modifying the DOM, render it again state 2. The bug appears when repainting from state 1 to state 2. The expected result HTML for the test is just a document directly written in state 2 (so there is no transition, no bug). This should work on all the platforms but there's problem with the time control between paints for state 1 and state 2 in the test HTML. I've tried three options: 1. Use setTimeout() to update the DOM - I really wouldn't like to use this because it slows down the test and can be flaky. 2. Use layoutTestController.display() before modifying the DOM to trigger a paint - calling this seems to make the test fail because display() starts tracking the paint rects which doesn't happen in the reference document. 3. Make use of requestAnimationFrame to time the paintings for state 1 and state 2 - doesn't work directly out-of-the-box because requestAnimationFrame schedules a full repaint after going into state 2 and the bug doesn't reproduce anymore. Is there a preferred solution to this problem or another one that I'm missing? Thanks, Andrei. ___ 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] Test the Web Forward
Hello WebKit community, We want to announce the W3C event Test the Web Forward hosted by Adobe. This hackathon builds off the Move the Web Forward initiative in order to help get developers more involved in contributing to the web platform we all work to define. During this hackathon, attendees will be learning about certain CSS and SVG features that need more tests in order to progress through the standards pipeline. Find more information on the official website http://testthewebforward.org/ Registration will open on June 1st and space is limited, so bookmark the dates (June 15th and 16th at the Adobe San Francisco office) and we hope to see you there! Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
On May 24, 2012, at 3:59 PM, Andrei Bucur wrote: No, I need a way to force a paint operation, similar to what layoutTestController.display() achieves, but without tracking the paint rectangles. Does anyone you find value in adding an optional parameter to display (or create another method on LTC) that disables paint rectangle tracking. The main advantage for such a change would be in extending the ref tests power to also cover repaint tests (at least a part of them), thus making pixel tests less necessary. Repaint bugs appear usually when the layout changes but the old pixels are incorrectly invalidated. By making the reference HTML directly identical to the test document after the bug triggering changes have been applied, it is pretty certain that the output pixels for the reference file will not contain the repaint artifacts (there's no repaint operation involved). When running such a test with a client that has the bug, it will fail because the test file output will have artifacts and the reference output will not. On the other hand, using a client with the repaint bug fixed, the pixels output for the test and reference files should be identical. Thoughts? I think this will be too fragile. It relies on the fact that a subsequent paint won't obscure the repaint bug that you're trying to detect. I'm much rather we work towards detecting repaint bugs via dumping the list of repaint rectangles. I don't think every test has to be a ref test. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
Ojan, As Simon states, some repaint tests will likely not be possible to write correctly as ref tests, but some of them I think they fit very well in the happy-no-pixel-test bucket :). If people decide it's a direction worth investigating, I'll give the idea a spin. Simon, On Fri, May 25, 2012 at 2:07 AM, Simon Fraser simon.fra...@apple.comwrote: I think this will be too fragile. It relies on the fact that a subsequent paint won't obscure the repaint bug that you're trying to detect. I'm much rather we work towards detecting repaint bugs via dumping the list of repaint rectangles. I don't think every test has to be a ref test. Don't the pixel tests face the same kind of risk, of a subsequent paint masking the repaint bug? Preserving this risk, but reducing the maintenance cost for the test is still an important improvement. Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
