1) where is the exact interface layer between QT and WEBKIT?
2) What are the APIs or Data structures, when we send data to WebCore for
parsing?
3) In which file, I can find the APIs and Data structure to send the data
for parsing and what is the data structure that WebCore is producing
(Please feel free to correct me if there is a better place to report
things like this)
http://bugs.webkit.org
For details:
http://webkit.org/quality/reporting.html
http://webkit.org/quality/lifecycle.html
--
Ariya Hidayat ([EMAIL PROTECTED])
Software Engineer, Qt Software, Nokia
On Sep 29, 2008, at 12:58 PM, Jason Hullinger wrote:
(reply all this time)
Well, it looks like stringByEvaluatingJavaScriptFromString is
calling: JSC::JSValue* scriptExecutionResult = coreFrame-loader()-
executeScript(WebCore::String(script), true); The problem, I
believe, is that
Thanks for the concrete examples, Dave! I tested all 3 of these, and
haven't yet found any problems. But I don't have specific URLs. I also
looked through the webkit bugs database as much as I could, and could not
locate them.
BTW - if the primary concern is not spinning the CPU, we could just
When I use setTimeouts, often the event has already occurred. So rather than
clamping, I'd suggest increasing the timeout up to 10ms rather than clamping it
at the start. Thus, if I specify 0, an immediate check would occur, then move
it up each time, maybe 1, 5, 10 would be optimum.
On
Sep 30, 2008, в 6:37 PM, Mike Belshe написал(а):
Thanks for the concrete examples, Dave! I tested all 3 of these,
and haven't yet found any problems. But I don't have specific
URLs. I also looked through the webkit bugs database as much as I
could, and could not locate them.
One
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application intended. In
the bug you mention, it mentions mapquest as a potential site with this
issue. But I can't reproduce that, and there are no specific URLs.
Mike
2008/9/30
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application
intended.
I don't quite agree - even though this may have been the intention,
the application developer will
I think we agree on this point - its a matter of what did the website author
intend. I believe there are legitimate cases to ask for setTimeout(1).
With a pure clamp based approach, this feature is not available today. On
the other hand, if the website author accidentally uses setTimeout(1),
Thanks, though this bug isn't a bug in WebKit. It's a bug in a layer of
a common WebKit port.
(Please feel free to correct me if there is a better place to report
things like this)
http://bugs.webkit.org
For details:
http://webkit.org/quality/reporting.html
Agreeing with Alexey's points here and adding one more...
On Sep 30, 2008, at 9:32 AM, Alexey Proskuryakov wrote:
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application
Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а):
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur
non-trivial processor usage.
- WBR, Alexey
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms minimum
timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we (Chromium folks) have not been as concerned
about CPU
On Sep 30, 2008, at 9:37 AM, Mike Belshe wrote:
Thanks for the concrete examples, Dave! I tested all 3 of these,
and haven't yet found any problems. But I don't have specific
URLs. I also looked through the webkit bugs database as much as I
could, and could not locate them.
When
BTW - if the primary concern is not spinning the CPU, we could just drop
the throttle down to 2 or 3ms, and the CPU will be largely idle on most
machines. In a few years, with faster processors, we'll be able to drop to
1ms and still have largely idle CPU.
Would 3ms be viable in your
Hi Peter,
On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote:
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason
On Sep 30, 2008, at 12:51 PM, Zan Dobersek wrote:
I'm getting interested in working on WebKit, MathML implementation,
to be a bit more precise.
However, I'm wondering if there are any needs or benefits of using a
specific operating system when considering WebKit development. At
the
Or there is option 3:
3) Restore the clamp for setTimeout and setInterval to 10ms for
compatibility, and add a new setHighResTimer API that does not have
any lower bound.
I'd like to tweak this suggestion a bit:
Let's make this new timer API object-oriented, so it can be both less
Fwiw, ActionScript 3 implements a Timer API we could use a basis:
http://livedocs.adobe.com/flex/2/langref/flash/utils/Timer.html
It basically is an OOP based timer/interval API.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Garen
Sent:
On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns [EMAIL PROTECTED] wrote:
The problem is not only confined to single processor systems. As others
have mentioned the bigger problem is the waste of resources. The length of
the timeout is not the full piece of the puzzle. There's also problems with
Yes, I guess that is the nicety of Objective-C and message passing.
I have tried to use initWithFrame with just a RECT set to {0, 0, 0, 0}, but
it fails. I believe this is because it's not a RECT from an actual window,
which is actually what I'm trying to get around using.
Would there be any
On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson [EMAIL PROTECTED] wrote:
If we add a new well specified API that all browser vendors agree on,
everybody wins.
No; everybody who's willing and able to change wins.
Everyone else wins or loses depending on whether the new behavior is better
or
On Sep 30, 2008, at 1:48 PM, Jason Hullinger wrote:
So it does seem possible to initWithFrame with some sort of default
values I assume? I've tried to initWithFrame({0, 0, 0, 0}, L,
L); (or a RECT with the same values) , but it fails at run time.
How exactly does it fail? It's hard to
On Tue, Sep 30, 2008 at 2:50 PM, David Hyatt [EMAIL PROTECTED] wrote:
Note that these problems in Safari came from having no clamp at all. Even
Chrome has a 1ms clamp.
Right. We weren't proposing making setTimeout() unclamped; just lowering
the clamp. (And I'm sorry for using the word
Subjective note:
I'm much more worried about sites spinning the CPU accidentally (e.g. they
used setTimeout(0) somewhere by accident) than I am about frame rates on
games. Using the clock as your frame rate is super buggy, and sites need to
know better. It won't work now and it won't work going
On Sep 30, 2008, at 10:42 AM, Peter Kasting wrote:
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we
On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Can you cite some of the existing sites that would benefit? That
would help others confirm the benefit and also estimate likelihood
of said sites adopting a new
On Sep 30, 2008, at 5:15 PM, Mike Belshe wrote:
On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:
Subjective note:
I'm much more worried about sites spinning the CPU accidentally
(e.g. they used setTimeout(0)
On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
It seems to these are demo pages, tutorials, or descriptions of
techniques. Clearly tutorials and demos can adapt to a new API, and
improving their current form is
One of the changes in Chrome's version of WebKit is that, instead of
storing pointers to the JS binding object for a core object in a
HashMap, it stores them directly in the core object. Although this
change is not currently in the webkit.org tree, and is in the Chrome
tree for the V8
On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I agree with you that web content authors should have a way to get called
back ASAP. It seems like we have three different proposals identified that
most have agreed are worth pursuing:
1) Design an improved timer
31 matches
Mail list logo
