Hi All,
I have been studying the JS execution and noticed that the JSGlobalData is
stored in a static variable and never deleted.
I traced even the windows port and noticed one more thing, that the
JSGlobalData and the Heap class destructor are never called. As it is
static I assume that the
So now to my question : Is it required to delete JSGlobalData and kill the GC
thread if we keep on re-creating the webview again and again without exiting
the process?
No.
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Hi,
Have you some news about dfg optimisations? what are you planing, what have
you now or what is your current work ?
Currently we do not have either LICM, or loop peeling, or GCSE. We do have
a patch that implements LICM, but we are letting it simmer for now because
under the current DFG IR,
At the WebKit contributor's meeting in April, we discussed a process for
importing third party tests into the WebKit repository (specifically, from the
W3C test repository).
I documented the process that we came up with at the meeting on the WebKit
wiki, here:
As I have said in the past, we should just import all tests, and treat
non-text, non-ref tests as pixel tests. If we wanted to reduce the number
of pixel tests we import, then we should submit those patches to W3C
instead of directly submitting them to WebKit.
In general, I don't buy the argument
Hi,
While taking a look into bug 83419 (about fast/transforms/scrollIntoView-
transformed.html) I faced with the following render issue:
When using Element::scrollInToView(true) on blocking elements that have bigger
child elements with margins webkit and Firefox show different results.
I
I agree. If nothing else, getting W3C tests into the WebKit repository will
help catch regressions.
From: Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org
To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com
Cc: WebKit Development
On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org wrote:
As I have said in the past, we should just import all tests, and treat
non-text, non-ref tests as pixel tests. If we wanted to reduce the number of
pixel tests we import, then we should submit those patches to W3C instead of
Dirk, my apologies, I was on travel the week you replied and missed your
message. I found it and will review / update now.
On 5/23/12 1:25 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org wrote:
As I have said in the past, we should
On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke dpra...@chromium.org wrote:
Not so: if the tests we had had 100% coverage, then importing more
tests would buy us nothing, but getting rid of the existing tests
would be quite unfortunate.
We certainly don't have 100% test coverage.
Clearly
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
The only sane argument I've heard so far to gate pixel tests is that the
correctness of such tests need to be manually inspected, which requires
a
lot of manual labor and is very error prone.
I'm assuming the above
On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
The only sane argument I've heard so far to gate pixel tests is that the
correctness of such tests need to be manually inspected, which requires
a
lot
On 5/23/12 2:30 PM, Maciej Stachowiak m...@apple.com wrote:
On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
The only sane argument I've heard so far to gate pixel tests is that
the
correctness of
On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com wrote:
Are you concerned just about the actual pixel results or also about keeping
render tree dumps up to date?
Both are more maintenance than a text-only test. In my experience,
maintaining pixel tests is more expensive, but
On May 23, 2012, at 3:13 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com wrote:
Are you concerned just about the actual pixel results or also about keeping
render tree dumps up to date?
Both are more maintenance than a
On Wed, May 23, 2012 at 2:59 PM, Jacob Goldstein jac...@adobe.com wrote:
As a side note to this discussion, there is talk in the W3C community
regarding their test approval process. At the recent working group
meetings in Germany the idea was floated to simply approve all tests that
are
16 matches
Mail list logo
