Re: [webkit-dev] Ever increasing binary size
On Mon, Apr 1, 2013 at 7:33 AM, Timothy Hatcher timo...@apple.com wrote: On Mar 22, 2013, at 3:12 AM, Ryosuke Niwa rn...@webkit.org wrote: WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB. WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB. Our binary size increased by 7.2% in just 4 months. Keep in mind that the Safari's Web Inspector is in the nightly. Also all of the frameworks and their resources are in the nightly twice (for 10.7 and 10.8). Safari's Web Inspector framework is around 2.5 MB (uncompressed) in r135421 and 4.2 MB in r145786. A 68% increase (that I will investigate further). Most of that size comes from image resources that can't be compressed further by the disk image. They are also duplicated for each OS, but the disk image compression should cancel that out. Also the WebKit Web Inspector is in the nightly. It is 5.1 MB (uncompressed) in r135421 and 6.3 MB in r145786. A 24% increase. Again, mostly images. That's an interesting point. It would indeed be more interesting to track the in-memory size of binaries than the file size. I think the first course of action we can take is to start tracking the binary size so that we may detect huge spikes. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to report iOS UIWebView WebKit issues
Hi All, I am developing an application using UIWebView on iPad I am seeing couple of WebCore (element style related) crashes. The crashes happens randomly (yet to narrow it down to exact use case), but the call stack is the same in all crashes. I want to know if bugs.webkit.org is the right place to log such issues? I know I have to provide a test html (so that it is easier for anyone to reproduce)along with other details, when I will log the issue. Could any one please confirm? Thanks, Rahaman ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to report iOS UIWebView WebKit issues
On 2013-04-03, at 03:51, Mustafizur Rahaman mustaf.h...@gmail.com wrote: Hi All, I am developing an application using UIWebView on iPad I am seeing couple of WebCore (element style related) crashes. The crashes happens randomly (yet to narrow it down to exact use case), but the call stack is the same in all crashes. I want to know if bugs.webkit.org is the right place to log such issues? I know I have to provide a test html (so that it is easier for anyone to reproduce)along with other details, when I will log the issue. Could any one please confirm? Please report them at http://bugreport.apple.com/ - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
For reference, here is a prototype patch which implements canvas opaque:
https://bugs.webkit.org/show_bug.cgi?id=112624
And one which implements getContext('2d', { alpha: none }):
https://bugs.webkit.org/show_bug.cgi?id=112628
I believe this represents the bulk of the cross-port work that would be
required; there is further port-specific work required, but this should be
mostly in platform/graphics/*.
Stephen
On Thu, Mar 14, 2013 at 5:23 PM, Dean Jackson d...@apple.com wrote:
On 15/03/2013, at 8:06 AM, Gregg Tavares g...@google.com wrote:
Because it's not the same as fillRect(0, 0, width, height) on an empty
canvas. The canvas itself has alpha (unless we add the option to not have
it as has been proposed). The contents of the canvas has to stay as the
user created it. If I draw with rgba(255,255,0, 0.5) I expect if I read
data out of the canvas or draw that canvas into another canvas I'll get
that color, not the color blended with the css background.
Yes, this is what I said in another email. Maybe I'm misunderstanding
this, but if the main concern is to guarantee nice subpixel-antialiased
text in canvas (but not anywhere else, such as the 99.99% of places where
people draw text) then well, I'm still not convinced opaque is a great
idea :) Especially not as an HTML attribute.
There are obviously ways to get around the problems you mentioned above
(e.g. two buffers + two draws, or keeping a display list until someone
wants to read out, etc) and, even more obviously, they have significant
problems. It just seems to me that we're trying to address the issue of
wanting nice looking text with a very specific solution on one element.
Maybe we should consider what we could do across the platform?
Dean
So, the canvas has to be blended if there's alpha. There's no magic
getting around that. The only way around it is to give the user a way to
say no alpha.
___
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] RenderLayer::isStackingContext() confusion
Background: According to CSS 2.1 spec, an element becomes a stacking context when: - it is positioned (relative, absolute, or fixed) - and it has a non-auto z-index Spec also mentions that there's room for expanding this definition; the examples I know about are fixed-position elements and elements with transforms. Questions: The implementation of RenderLayer::isStackingContext() looks fishy. It only checks for a non-auto z-index. It does not check for the positioning style of the layer. There is no indication that it checks for any more recent special cases such as fixed-position or transforms. Is this function name a misnomer? should it actually be renamed to hasNonAutoZIndex() ? If the additional criteria is not being checked inside this helper function, then where is it? I see some code in collectLayers that looks vaguely similar to checking whether an element is positioned, but what about all the other uses of isStackingContext everywhere? Thanks! Shawn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderLayer::isStackingContext() confusion
The function does what it says, it's just not obvious why: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/css/StyleResolver.cppsq=package:chromiumtype=csq=adjustRenderStylel=1469 First we set the z-index to be auto for static position elements. Next we set the z-index to be 0 for elements based on the big set of cases in adjustRenderStyle, and then you can tell in RenderLayer if you're a stacking context based on if you have z-index != auto. I'd add a comment explaining. The alternative is to check that big set of cases every time someone calls isStackingContext but that might be slower. Changing the name of the method would make the code more confusing, since it is checking the right thing just through some complicated process. On Wed, Apr 3, 2013 at 3:48 PM, Shawn Singh shawnsi...@chromium.org wrote: Background: According to CSS 2.1 spec, an element becomes a stacking context when: - it is positioned (relative, absolute, or fixed) - and it has a non-auto z-index Spec also mentions that there's room for expanding this definition; the examples I know about are fixed-position elements and elements with transforms. Questions: The implementation of RenderLayer::isStackingContext() looks fishy. It only checks for a non-auto z-index. It does not check for the positioning style of the layer. There is no indication that it checks for any more recent special cases such as fixed-position or transforms. Is this function name a misnomer? should it actually be renamed to hasNonAutoZIndex() ? If the additional criteria is not being checked inside this helper function, then where is it? I see some code in collectLayers that looks vaguely similar to checking whether an element is positioned, but what about all the other uses of isStackingContext everywhere? Thanks! Shawn ___ 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] Thank You
I’m writing to say thank you, personally, and on behalf of the Chromium project. Chromium could not have happened without WebKit and the help of its contributors. As you likely have seen, Adam just posted http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html announcing Blink, which is a departure from our previous WebKit workflow. I hope that others will see Blink as I do: as a chance to take the WebKit codebase to exciting new places. I hope someday that many of the ideas we pursue in Blink will find their way into many platforms, including WebKit. For those interested in the technical details, we’ll be posting more of our thoughts and plans to blink-...@chromium.org. WebKit and Chromium have a long, shared history, and we hope to continue our relationship. We will be available on #webkit and webkit-dev and hope to continue our connections with this great community for years to come. Thank you again. Eric p.s. Adam and I are happy to work with other reviewers to remove PLATFORM(CHROMIUM) code and other messes we may have caused over the years from webkit.org. Adam and I are still running queues.webkit.org and associated EWS/CQ/sherriff-bot and plan to do so for the next few weeks as we work to transition them to new owners. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Thank You
On Wed, Apr 3, 2013 at 2:02 PM, Eric Seidel e...@webkit.org wrote: p.s. Adam and I are happy to work with other reviewers to remove PLATFORM(CHROMIUM) code and other messes we may have caused over the years from webkit.org. Adam and I are still running queues.webkit.org and associated EWS/CQ/sherriff-bot and plan to do so for the next few weeks as we work to transition them to new owners. Ditto for the flakiness dashboard at test-results.appspot.com. Ping me if you'd like to be the new owner for it. :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderLayer::isStackingContext() confusion
Thanks for the explanation. I submitted a patch, just in case reviewers agree that a comment is appropriate there. But I won't argue strongly either way. https://bugs.webkit.org/show_bug.cgi?id=113909 On Wed, Apr 3, 2013 at 1:18 PM, Elliott Sprehn espr...@chromium.org wrote: The function does what it says, it's just not obvious why: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/css/StyleResolver.cppsq=package:chromiumtype=csq=adjustRenderStylel=1469 First we set the z-index to be auto for static position elements. Next we set the z-index to be 0 for elements based on the big set of cases in adjustRenderStyle, and then you can tell in RenderLayer if you're a stacking context based on if you have z-index != auto. I'd add a comment explaining. The alternative is to check that big set of cases every time someone calls isStackingContext but that might be slower. Changing the name of the method would make the code more confusing, since it is checking the right thing just through some complicated process. On Wed, Apr 3, 2013 at 3:48 PM, Shawn Singh shawnsi...@chromium.orgwrote: Background: According to CSS 2.1 spec, an element becomes a stacking context when: - it is positioned (relative, absolute, or fixed) - and it has a non-auto z-index Spec also mentions that there's room for expanding this definition; the examples I know about are fixed-position elements and elements with transforms. Questions: The implementation of RenderLayer::isStackingContext() looks fishy. It only checks for a non-auto z-index. It does not check for the positioning style of the layer. There is no indication that it checks for any more recent special cases such as fixed-position or transforms. Is this function name a misnomer? should it actually be renamed to hasNonAutoZIndex() ? If the additional criteria is not being checked inside this helper function, then where is it? I see some code in collectLayers that looks vaguely similar to checking whether an element is positioned, but what about all the other uses of isStackingContext everywhere? Thanks! Shawn ___ 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] Thank You
Whether Bugs fixing, Feature development will be up-streamed to WebKit trunk? or it will live with Blink itself? On 4 April 2013 02:32, Eric Seidel e...@webkit.org wrote: I’m writing to say thank you, personally, and on behalf of the Chromium project. Chromium could not have happened without WebKit and the help of its contributors. As you likely have seen, Adam just posted http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html announcing Blink, which is a departure from our previous WebKit workflow. I hope that others will see Blink as I do: as a chance to take the WebKit codebase to exciting new places. I hope someday that many of the ideas we pursue in Blink will find their way into many platforms, including WebKit. For those interested in the technical details, we’ll be posting more of our thoughts and plans to blink-...@chromium.org. WebKit and Chromium have a long, shared history, and we hope to continue our relationship. We will be available on #webkit and webkit-dev and hope to continue our connections with this great community for years to come. Thank you again. Eric p.s. Adam and I are happy to work with other reviewers to remove PLATFORM(CHROMIUM) code and other messes we may have caused over the years from webkit.org. Adam and I are still running queues.webkit.org and associated EWS/CQ/sherriff-bot and plan to do so for the next few weeks as we work to transition them to new owners. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
