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
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
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
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
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?
-
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,
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
