[webkit-dev] Garbage Collection doesn't fire in time for Video/Audio element removing
Hi, all, When creating the new video element or audio element and remove it by clearing the innerHTML of parent div node, the used memory will be growing for each time. I doubt if there is no specified garbage collection mechanism for this situation. The testing was checked with Mac Safari 6.0 and the MiniBrowser which is provided in the WebKit project. That is not a good idea to launch the GC while the video element is removed from the document. But, what is the good solution? Would you please comment it? Thanks in advance. --- Horky Sent with Sparrow (http://www.sparrowmailapp.com/?sig) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New script to import W3C CSS tests
Hi Dirk Everyone, Dirk, your question about this in IRC the other day was timely indeed. I've recently written a batch of tests for CSS Regions that I intend to submit to both the W3C and Webkit (and have planned more to come). Rather than push two slightly different versions of the same tests to each repo, and to address how these tests are to be maintained over time, I took a stab automating the import and just submitted a patch [1]. I know this conversation was started a while ago as I attended the WK Contributor's meeting last spring where my colleagues Jacob Goldstein and Alan Stearns led the discussion. I was sort of new onto the scene then and was pretty much a lurker in the meeting, so you probably don't remember me. I recall that much of the debate was about handling failing tests, approved vs. submitted, duplicates, etc. Since all I've done is automate the mechanics of the import itself, I have not solved a lot of those issues, but the conversion of tests certainly had its own set of things to consider. I figured I would put this one piece in place, get feedback on it, and hopefully resurrect the discussion on fitting this into the bigger picture. A great goal would be to have this script run on an automated schedule and to extend it to deal with test results, expected failures, etc. All of the dirty details are in the ChangeLog of the patch and in the script headers, but I basically tried to cover #8 from last spring's meeting notes [2]. I think the script covers all of those bullets, with that last bullet as sort of. I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Dirk, when you have a chance, take a look. Review it with gusto as you say. And anyone else who's interested, your feedback is welcome. I fairly certain this will go a few rounds before it's settled. :) Cheers, -Rebecca [1] https://bugs.webkit.org/show_bug.cgi?id=111513 [2] http://trac.webkit.org/wiki/ImportingThirdPartyTests ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Should we create an 8-bit path from the network stack to the parser?
Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Garbage Collection doesn't fire in time for Video/Audio element removing
On Mar 7, 2013, at 3:07 AM, Horky ho...@sina.com wrote: When creating the new video element or audio element and remove it by clearing the innerHTML of parent div node, the used memory will be growing for each time. I doubt if there is no specified garbage collection mechanism for this situation. The testing was checked with Mac Safari 6.0 and the MiniBrowser which is provided in the WebKit project. That is not a good idea to launch the GC while the video element is removed from the document. But, what is the good solution? Would you please comment it? Please file a bug report. It’s improper WebKit project etiquette to report a bug with email to webkit-dev. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ 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] Should we create an 8-bit path from the network stack to the parser?
No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ 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] Should we create an 8-bit path from the network stack to the parser?
The HTMLTokenizer still works in UChars. There's likely some performance to be gained by moving it to an 8-bit character type. There's some trickiness involved because HTML entities can expand to characters outside of Latin-1. Also, it's unclear if we want two tokenizers (one that's 8 bits wide and another that's 16 bits wide) or if we should find a way for the 8-bit tokenizer to handle, for example, UTF-16 encoded network responses. Adam On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote: No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ 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] Should we create an 8-bit path from the network stack to the parser?
The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. - Michael On Mar 7, 2013, at 11:11 AM, Adam Barth aba...@webkit.org wrote: The HTMLTokenizer still works in UChars. There's likely some performance to be gained by moving it to an 8-bit character type. There's some trickiness involved because HTML entities can expand to characters outside of Latin-1. Also, it's unclear if we want two tokenizers (one that's 8 bits wide and another that's 16 bits wide) or if we should find a way for the 8-bit tokenizer to handle, for example, UTF-16 encoded network responses. Adam On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote: No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ 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] Should we create an 8-bit path from the network stack to the parser?
Yes, I understand how the HTML tokenizer works. :) Adam On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. - Michael On Mar 7, 2013, at 11:11 AM, Adam Barth aba...@webkit.org wrote: The HTMLTokenizer still works in UChars. There's likely some performance to be gained by moving it to an 8-bit character type. There's some trickiness involved because HTML entities can expand to characters outside of Latin-1. Also, it's unclear if we want two tokenizers (one that's 8 bits wide and another that's 16 bits wide) or if we should find a way for the 8-bit tokenizer to handle, for example, UTF-16 encoded network responses. Adam On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote: No. I retract my question. Sounds like we already have it right! thanks for setting me straight. Maybe some day we could make a non copying code path that points directly at the data in the SharedBuffer, but I have no idea if that'd be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? - Michael On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote: Hi folks. Today, bytes that come in from the network get turned into UTF-16 by the decoding process. We then turn some of them back into Latin-1 during the parsing process. Should we make changes so there’s an 8-bit path? It might be as simple as writing code that has more of an all-ASCII special case in TextCodecUTF8 and something similar in TextCodecWindowsLatin1. Is there something significant to be gained here? I’ve been wondering this for a while, so I thought I’d ask the rest of the WebKit contributors. -- Darin ___ 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] Should we create an 8-bit path from the network stack to the parser?
On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. On Mar 7, 2013, at 2:16 PM, Adam Barth aba...@webkit.org wrote: Yes, I understand how the HTML tokenizer works. :) I didn't understand these details, and I really appreciate Michael describing them. I'm also glad others on the mailing list had an opportunity to get something out of this. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Spelling document markers: Design question
Howdy folks, The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? Thank you all for thoughts and suggestions! Cheers, Rouslan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New script to import W3C CSS tests
On Thu, Mar 7, 2013 at 8:46 AM, Rebecca Hauck rha...@adobe.com wrote: Hi Dirk Everyone, Dirk, your question about this in IRC the other day was timely indeed. I've recently written a batch of tests for CSS Regions that I intend to submit to both the W3C and Webkit (and have planned more to come). Rather than push two slightly different versions of the same tests to each repo, and to address how these tests are to be maintained over time, I took a stab automating the import and just submitted a patch [1]. I know this conversation was started a while ago as I attended the WK Contributor's meeting last spring where my colleagues Jacob Goldstein and Alan Stearns led the discussion. I was sort of new onto the scene then and was pretty much a lurker in the meeting, so you probably don't remember me. I recall that much of the debate was about handling failing tests, approved vs. submitted, duplicates, etc. Since all I've done is automate the mechanics of the import itself, I have not solved a lot of those issues, but the conversion of tests certainly had its own set of things to consider. I figured I would put this one piece in place, get feedback on it, and hopefully resurrect the discussion on fitting this into the bigger picture. A great goal would be to have this script run on an automated schedule and to extend it to deal with test results, expected failures, etc. All of the dirty details are in the ChangeLog of the patch and in the script headers, but I basically tried to cover #8 from last spring's meeting notes [2]. I think the script covers all of those bullets, with that last bullet as sort of. I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Dirk, when you have a chance, take a look. Review it with gusto as you say. And anyone else who's interested, your feedback is welcome. I fairly certain this will go a few rounds before it's settled. :) Thanks, Rebecca! It will be great if we can start regularly importing and running the W3C's tests. (I'll review the patch and post any other comments on the bug). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New script to import W3C CSS tests
I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Is there any way we can merge the two scripts so there is only one import/exporter than handles both performance and CSS test suites? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New script to import W3C CSS tests
On Thu, Mar 7, 2013 at 3:04 PM, Tony Gentilcore to...@chromium.org wrote: I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Is there any way we can merge the two scripts so there is only one import/exporter than handles both performance and CSS test suites? That is a good question, and something I'll be looking at as part of this :). More generally, I'm trying to look into importing and running tests from the w3c across the board as one of my next projects. Rebecca beat me to it! -- Dirk -Tony ___ 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] New script to import W3C CSS tests
On 3/7/13 3:26 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Mar 7, 2013 at 3:04 PM, Tony Gentilcore to...@chromium.org wrote: I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Is there any way we can merge the two scripts so there is only one import/exporter than handles both performance and CSS test suites? I thought about it. There are only a couple similar pieces between the two scripts, but since the perf importer is relatively short, there's no reason why the code couldn't be consolidated into one module with separate execution paths. I figured I'd start this out atomically and then figure out how it can all plug in. That is a good question, and something I'll be looking at as part of this :). More generally, I'm trying to look into importing and running tests from the w3c across the board as one of my next projects. Rebecca beat me to it! -- Dirk -Tony ___ 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] WebKit Contributors Meeting - Save the Date
I'm excited! As usual, I've added the wiki page: http://trac.webkit.org/wiki/May%202013%20Meeting - R. Niwa On Tue, Mar 5, 2013 at 3:30 PM, Sam Weinig wei...@apple.com wrote: Hi all, Apple will once again be hosting a WebKit Contributors Meeting. It will be held at the DoubleTree by Hiltonhttp://doubletree3.hilton.com/en/hotels/california/doubletree-by-hilton-hotel-san-jose-JOSE-DT/index.html Hotel in San Jose on Thursday, May 2nd and Friday, May 3rd. As with the meeting in previous years, this event will have an unconference-like format, allowing plenty of time for impromptu sessions/discussions and hacking. We will open registration in the coming weeks. The meeting will be free of charge. All WebKit contributors are encouraged to attend. We hope to see you there! Thanks, Sam ___ 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] PSA: --profile works in run-webkit-tests now too
As of http://trac.webkit.org/changeset/144719 --profile and --profiler= work in run-webkit-tests, just like they do in run-perf-tests. For example you can find out why your/favorite/tests are so slow with: run-webkit-tests your/favorite/tests --profile RWT will sample each DRT instance and print out instructions on how to view it (or show you the top 10 samples if you're on an OS with command-line). On my Mac, it says something like: iprofiler: Profiling process 21958 (DumpRenderTree) for 10 seconds iprofiler: Session saved at /Users/eseidel/Projects/WebKit/Source/WebKit/chromium/webkit/Release/layout-test-results/test-72.dtps I've found these incredibly useful for making WebKit faster, and I hope you do too. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
