Re: [webkit-dev] setTimeout as browser speed throttle
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote: In short, our architecture makes me more willing to take risks with setTimeout clamping than I would be otherwise. This is a good thing I think because we have the opportunity to test this out and get more data without risking as much. I guess I don't expect it to make a huge difference but if you would like to test a value higher than 1ms but less than 10ms in live code I'd certainly love to hear the results. When we have that data, we'll share it. I'm not sure when that will happen. Are you planning to test a specific alternate interval? I don't know what Mike is planning to do exactly. I think we just disagree here. In my opinion since setTimeout clamping is so varied across browsers and even varies in Firefox depending on whether or not a flash animation is going, the expectation of consistent clamping has to be low. Or at least it has to be the case that it doesn't matter much if different browsers have different clamping values in practice. So I think there is room to do interesting things related to different power management states. Anyways, I'm just telling you what we are considering doing. I'm not really talking about developer expectation here so much as the possibility that, if indeed a lower clamp is a performance improvement for real sites, then said sites would noticeably slow down the moment you unplug. As a user I would find that surprising and weird. My laptop slows down considerably when I unplug it because of power saving settings. I don't find that too unusual. Mine doesn't. Instead it slews the CPU clockspeed based on workload and shuts down components (including the CPU) whenver possible. Get a Mac. :-) In all seriousness, I see your point for Windows machines. User expectations for the unplugged state may be lower. Yeah, OK ;-) (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Javascript window.open handling in GTK
On Wed, 2008-10-01 at 15:18 -0700, Weber, Bernd wrote: Playing around with the code for a while now I found that, at least in the GTK implementation, window.open(), close(), etc is not implemented. Can anyone explain to me why this is not implemented? Maybe because of security concerns? Wouldn’t it be better to have a setting defined that restricts this feature instead of not implementing it at all?! I think mostly because code has not been written or has not been reviewed/commited yet. I think what you are trying to do will probably be helped by these: https://bugs.webkit.org/show_bug.cgi?id=19130 https://bugs.webkit.org/show_bug.cgi?id=16401 See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database Storage
Hi, The database storage (like cookies, localStorage and sessionStorage) is stored locally. So everyone can modify it, you can't rely on it. It's really easy to do so with the Database panel in the Web Inspector. Anthony. Le 3 oct. 08 à 02:45, Loll a écrit : Hi, Im not sure if this is the right place to ask this or not, so im sorry in advance if it is. I am interested in the database Storage that is now available through webkit and had a few questions about it. My main point of interest is in the security of it. Right now, the website I develop uses PHP and information is stored using PHP sessions. From a servers point of view I can see a lot of advantages of storing such data locally. For one thing , its lot less reads and writes to the server, making it a bit faster I would expect. But how secure is the data? is it secure enough to reliably put such info on a clients system? Im not talking about bank data here, but I am looking at data that I would not want to be altered or viewed in its raw format all the same. Is it safe to assume that no one is going to get into it , any more than its safe to assume that no one is going to hijack a PHP Session to gain access to the same data? Anyway I just wondered if was a good idea to think about moving in the direction of local storage vs server storage and what level of data should be safely stored that way, vs what shouldn't be stored that way. Thanks Loll ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 3, 2008, at 12:21 PM, Rob Burns wrote: On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Since I fear the logic here has been lost let me try to summarize what I'm trying to say on this topic. • setTimeout gets used in cases where it is not always the best solution for authors: i.e., using for polling when a specified event would be a better way to provide interactivity • setTimeout is probably most often tested on IE with a clamp of 15ms and any author testing elsewhere does not focus on power consumption issues • for these cases where it is not being used correctly, a user of Chrome (with a 1ms clamp) will experience 15X processor use over a user of IE (with 15ms clamp) • the 15x processor utilization will result in an accelerated power drain on mobile devices running Chrome compared to those running IE • most users will not diagnose the issue down to a specific tab or a specific page, but may at times identify the browser or the platform as the problem My approach to dealing with this is to leave any number of pages I desire open in Safari my main browser and avoid flash and javascript entirely there. If a page requires javascript, I fire up Shira or Opera or another browser with javascript and flash enabled and make sure I quit the application before I go on battery or immediately after viewing the page. This gives me immensely more battery life than I would otherwise have given my usage patterns (like having a second or even a third battery). Take care, Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Darin, On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote: On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns [EMAIL PROTECTED] wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob It's a good question. I suspect though that it could break sites. Imagine a calendar application that wishes to periodically wake up to see if it should put up an alert to notify you of an upcoming event. Such a feature probably requires the ability to run a timer. Yes, understood. But this example also requires javascript enabled. If a user disables javascript this web app will not work either. I'm suggesting WebKit could allow more finegrained control by allowing javascript enabled, but timers disabled. Also this example illustrates how an author of such a calendar web app may use setTimeout as a polling device rather than using an event- based approach where the application simply sets event timers for those alerts. By allowing greater control over disabling setTimeout, the authoring community will be forced to learn about better approaches to authoring such a web app. Obviously this stuff won't happen tomorrow, but we have to take a long view of it from time to time and think about what we can do to get there. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] emitting a click on the page
Hello. I'm interested it there's a way to emit a click signal with the given X,Y coordinate to the current page being shown. There probably is an event handler but I don't know where and how to hook my own click function to it. If there is, can I please get a hint how to do that. Greets, Luka ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 3, 2008, at 3:10 AM, Rob Burns wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). There are web apps that a user may legitimately want to continue to work in the background. One obvious example is a web-based audio player, although in that case it would be a plugin or audio element continuing to do work. Still, if you're going to allow plugins and media elements to continue, you may as well allow timers. Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. Given these kinds of examples, I think pausing anything in a background tab would not be a good choice; if that kind of functionality were on offer it should be a more explicit user gesture. All in all, I think we shouldn't overreact on the timer issue. Sites that consume egregious amounts of computing resources, whether through timers or otherwise, are the minority, and so long as they suck in all browsers and not just some, users will blame the site and it will be pressured to change. So really (in my opinion), matching or beating the CPU consumption of other browsers is the target, and we shouldn't go crazy with novel ways to restrict timers or anything else. Just avoid looking broken on sites that were only tested in IE or Firefox. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Maciej, On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote: On Oct 3, 2008, at 3:10 AM, Rob Burns wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). There are web apps that a user may legitimately want to continue to work in the background. One obvious example is a web-based audio player, although in that case it would be a plugin or audio element continuing to do work. Still, if you're going to allow plugins and media elements to continue, you may as well allow timers. Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. Given these kinds of examples, I think pausing anything in a background tab would not be a good choice; if that kind of functionality were on offer it should be a more explicit user gesture. I agree with that. To me burying a tab is an explicit and often deliberate user gesture. It would take novice users little time to adjust to the pausing of buried tabs (pausing with respect to all processing: plugins, animated images, and javascript for example). If audio is playing and it pauses because the tab is buried, the user will quickly come to understand that the tab needs to be exposed and to switch to a new window to create the new tab. The audio still plays in a background window, just not in a background tab. Until tab management gets up to speed, that would be a prudent approach anyway. All in all, I think we shouldn't overreact on the timer issue. Sites that consume egregious amounts of computing resources, whether through timers or otherwise, are the minority, and so long as they suck in all browsers and not just some, users will blame the site and it will be pressured to change. So really (in my opinion), matching or beating the CPU consumption of other browsers is the target, and we shouldn't go crazy with novel ways to restrict timers or anything else. Just avoid looking broken on sites that were only tested in IE or Firefox. My experience is that the problem is much more of a problem (but I'm mobile a lot). Adding a new highres timer is a good step, but if that's already available, then providing setTimeout a 15 fold difference in clamps between WebKit and IE (the primary test browser) will really exacerbate the problem (perhaps as much as a significant percentage loss in battery-charge-life). As for trying to avoid restricting timers that merely leads to restricting javascript in total. The only reason I would ever want to turn off javascript is to control poorly authored timers (and similar poorly authored plugins and plugin authoring). So I lose all javascript support simply to avoid timers, where I would prefer to lose the timer capabilities and still have the remaining javascript or maintain all javascript and lose timers for buried tabs. If we assume the new highres API will not be abused the way setTimeout is
Re: [webkit-dev] setTimeout as browser speed throttle
On 03/10/2008, at 14:16, Maciej Stachowiak wrote: [...] Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. [...] Maybe the new Timer API should be extended with an option for: should this timer be executed when the page is hidden in a background tab. Animation timers would then specify no, thereby reducing amount of cpu/ battery consumed. GMail could specify yes: low-overhead update of the unread count in background. It would make sense to have the default to be false, and to be the last parameter. - Peter Speck ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On 03/10/2008, at 03:50, Aaron Boodman wrote: One other random idea. What about mixing up the param order for parallelism with the existing timer APIs: Timer startTimer(Function callback, double delay, bool repeating); [...] Which feels more familiar, but at the same timer better. Less new things to remember. Also, I think this argues for the unit to continue being milliseconds, again, for familiarity. Agree on both terms. Fractional milliseconds are awkward when coming from a Cocoa programming world, but in the html/JS world the basic unit of time is milliseconds: the Date object uses milliseconds, whereas Cocoa's NSDate uses seconds. Having the same parameters as current API but with duration in seconds rather than milliseconds will create lots of bugs for web-developers. That's would be a definite gotcha. - Peter Speck ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Are you planning to test a specific alternate interval? I believe Mike is raising the Chromium clamp to 4 ms. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Thu, Oct 2, 2008 at 10:00 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Here it is: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html Thanks for writing this up, Maciej, it looks great to me. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On 03/10/2008, at 19:09, Mike Belshe wrote:
I'm not opposed to any of this; and the new API is definitely
nicer. I'll bring up a devil's advocate point. One thing I hate is
the Microsoft-style smorgasboard of APIs. When you want to start a
timer, you have 6 to choose from, and I hope we can avoid similar
problems in the DOM. If keeping the number of APIs is a worthy
goal, we could just augment the existing API in a backward
comaptible way:
setTimeout(callback, milliseconds, protect_against_cpu_looping =
true)
Example to set a 1us timer:
setTimeout(foo(), 0.001, false)
And future extensions would add even more parameters.
The Google Map API uses an object for such extra parameters, e.g.
setTimeout(foo(), 0.001, { throttle:false, runInBackground:true });
This would allow for future extensions without adding new methods/
classes; without having to add yet another API method.
- Peter Speck
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood [EMAIL PROTECTED]wrote: I'd say define it as a minimum precision of 1ms, but browser manufacturers can define any precision they wish. OK, but that only pushes the problem space outward rather than solving it. Make CPUs 10x faster and then have one browser with a floor of 1 ms and one with 0.1 ms and you have the exact scenario we're in today. Someone writes a tight loop in the 1 ms browser, checks that it doesn't use too much CPU, and pushes the build, and the 0.1 ms browser gets hosed. I admit that this one worries me a bit. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] shiftLeft property compatibility
We at CNS Vital Signs would like to request that the shiftLeft property for the keydown and keyup events be implemented in the Safari web browser. CNS Vital Signs has developed software that presents a series of computerized neurocognitive tests that are designed to be used as a routine part of a clinical practice, as a research instrument, and in schools or workplaces where health and safety are an issue. The CNS Vital Signs test battery offers 54 languages and has been utilized as a research tool in over 35 countries world wide. The tests run on a PC and are designed to collect responses from patients and calculate performance scores based on the accuracy and timing of the response. The original program was a stand-alone application that is downloaded and installed on the PC. We have recently released a web version of the same program. One of the tests originally written makes use of the right and left shift keys. Patients are asked to press the left shift key or the right shift key to respond to a presented rule. Currently, only Internet Explorer has implemented the shiftLeft property for the keydown and keyup events. Our pharmacutical customers require the web version of our test be identical in nature to the local version, so we have had to restrict all web deployments to support Internet Explorer only. We have programmed the web application to use the right and left arrow keys for other browsers but we have had to restrict it's use to clinical practice use. Thanks for considering our request. David J. Ford VP Quality Assurance CNS Vital Signs, LLC https://www.cnsvs.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] shiftLeft property compatibility
On Oct 3, 2008, at 10:48 AM, David Ford wrote: We at CNS Vital Signs would like to request that the shiftLeft property for the keydown and keyup events be implemented in the Safari web browser. Can you please file an enhancement request at http://webkit.org/new- bug? - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
Hi Maciej.
Cameron McCormack:
If possible, it would be nice if there could be some degree of
compatibility between this proposed API and the one in SVG Tiny
1.2:
http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
Maciej Stachowiak:
I considered that, but I don't like the fact that it makes the
common
zero-delay continuation callback case into three lines of code
instead
of one, for what I think is no practical benefit.
Justin’s proposed API seems to need four lines for that case:
var t = new Timer();
t.repeatCount = 1;
t.addEventListener('timercomplete', function() { … }, false);
t.start();
compared with the three for SVG’s timer:
var t = createTimer(0, -1);
t.addEventListener('SVGTimer', function() { … }, false);
t.start();
See my proposal on another thread, which makes this:
startTimer(0, false, function() { ... });
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the timer immediately, as in your example. Or you
could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
etc.
And you could easily add animation or media API's for synchronization:
var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
var transition = window.getTransitionForElement(element, left);
transition.trigger(t);
...
element.style.left = 100px;
This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.
-
~Chris
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
Again, I'm wondering how many legitimate uses are there for short timeouts in background tabs/windows. In a background window: animation video audio work queues for database or other background processing something interesting the web hasn't invented yet To give you some context, Safari used to throttle plug-in timers for background windows. The result was that users would see randomly choppy content. In a background tab: audio work queues for database or other background processing something interesting the web hasn't invented yet Also note that protections for background windows and tabs wouldn't solve the majority of the problem we've seen in the wild, which is the *foreground* window going crazy in a single-tabbed browsing session. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
Hi Chris.
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the timer immediately, as in your example.
I think Maciej has made a convincing case that new Timer is a bit
too coy about the fact that the timer is actually starting.
Or you could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I like your suggestion of adding startOneShot (and
startRepeating?) to the API. I think it would improve clarity over a
bool parameter specifying whether the timer repeats.
To create a Timer that isn't scheduled to fire:
new Timer(...)
To create a Timer that is scheduled to fire:
new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)
Or, if we don't like constructors:
createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)
And you could easily add animation or media API's for synchronization:
var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
var transition = window.getTransitionForElement(element, left);
transition.trigger(t);
...
element.style.left = 100px;
This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.
This would be really cool!
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database Storage
To expand on this point, The data you store on your user's system should be your user's data. It should belong to them, and therefore security concerns about what they do with it should be moot. You can, of course, encrypt the data or otherwise obfuscate it before storing it in the database, but that's not enough to keep them from poking around messing with it. First rule of computer security - all security measures are worthless if the attacker gains physical access to the machine. ~Brady On Oct 3, 2008, at 3:29 AM, Anthony Ricaud wrote: Hi, The database storage (like cookies, localStorage and sessionStorage) is stored locally. So everyone can modify it, you can't rely on it. It's really easy to do so with the Database panel in the Web Inspector. Anthony. Le 3 oct. 08 à 02:45, Loll a écrit : Hi, Im not sure if this is the right place to ask this or not, so im sorry in advance if it is. I am interested in the database Storage that is now available through webkit and had a few questions about it. My main point of interest is in the security of it. Right now, the website I develop uses PHP and information is stored using PHP sessions. From a servers point of view I can see a lot of advantages of storing such data locally. For one thing , its lot less reads and writes to the server, making it a bit faster I would expect. But how secure is the data? is it secure enough to reliably put such info on a clients system? Im not talking about bank data here, but I am looking at data that I would not want to be altered or viewed in its raw format all the same. Is it safe to assume that no one is going to get into it , any more than its safe to assume that no one is going to hijack a PHP Session to gain access to the same data? Anyway I just wondered if was a good idea to think about moving in the direction of local storage vs server storage and what level of data should be safely stored that way, vs what shouldn't be stored that way. Thanks Loll ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database Storage
Not discussed yet is that data is secured between JavaScript from a web page on Site A accessing data originally stored from a web page on Site B. This is not allowed. Note that a web page served from http://www.domain.com/ cannot access a database saved from a web page served from http://domain.com/, and vice-versa. The protocol (or scheme), hostname, and (implied) port number must all match before the database is accessible. Dave On Fri, 10/3/08, Brady Eidson [EMAIL PROTECTED] wrote: To expand on this point, The data you store on your user's system should be your user's data. It should belong to them, and therefore security concerns about what they do with it should be moot. You can, of course, encrypt the data or otherwise obfuscate it before storing it in the database, but that's not enough to keep them from poking around messing with it. First rule of computer security - all security measures are worthless if the attacker gains physical access to the machine. ~Brady On Oct 3, 2008, at 3:29 AM, Anthony Ricaud wrote: Hi, The database storage (like cookies, localStorage and sessionStorage) is stored locally. So everyone can modify it, you can't rely on it. It's really easy to do so with the Database panel in the Web Inspector. Anthony. Le 3 oct. 08 à 02:45, Loll a écrit : Hi, Im not sure if this is the right place to ask this or not, so im sorry in advance if it is. I am interested in the database Storage that is now available through webkit and had a few questions about it. My main point of interest is in the security of it. Right now, the website I develop uses PHP and information is stored using PHP sessions. From a servers point of view I can see a lot of advantages of storing such data locally. For one thing , its lot less reads and writes to the server, making it a bit faster I would expect. But how secure is the data? is it secure enough to reliably put such info on a clients system? Im not talking about bank data here, but I am looking at data that I would not want to be altered or viewed in its raw format all the same. Is it safe to assume that no one is going to get into it , any more than its safe to assume that no one is going to hijack a PHP Session to gain access to the same data? Anyway I just wondered if was a good idea to think about moving in the direction of local storage vs server storage and what level of data should be safely stored that way, vs what shouldn't be stored that way. Thanks Loll ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote:
I'm not opposed to any of this; and the new API is definitely
nicer. I'll bring up a devil's advocate point. One thing I hate is
the Microsoft-style smorgasboard of APIs. When you want to start a
timer, you have 6 to choose from, and I hope we can avoid similar
problems in the DOM. If keeping the number of APIs is a worthy
goal, we could just augment the existing API in a backward
comaptible way:
setTimeout(callback, milliseconds, protect_against_cpu_looping =
true)
Example to set a 1us timer:
setTimeout(foo(), 0.001, false)
setInterval could be modified similarly.
There are some downsides; such as difficulty of knowing what
resolution your browser supports; but maybe that is an advantage as
well. You also lose the new features, and OO style. But, it does
avoid API-soup.
I did consider this possibility, but it is not backwards compatible.
Many browsers, including WebKit and Gecko based ones, pass any
arguments to setTimeout past delay to the timeout function. So
setTimeout(foo, 0.001, false) would call foo with a first parameter of
false. Since this construct already has a meaning, I don't think we
can change it for only the boolean case.
I agree with you that excess of APIs can confuse Web developers.
Normally our preference is to extend existing facilities. Thus the
WebKit project's focus on extending existing technologies like HTML
and CSS, as opposed to investing heavily in total reinventions like
XForms. Not only are ocean-boiling excercises a waste of time for
authors, but we as browser engine developers will have to continue to
support the older technologies forever anyway.
In this case, I think the preponderance of the evidence weighs in
favor of new API, in part because the existing calls are impossible to
extend compatibly with extra arguments, and because it is likely
desirable to feature-test for highres timers, and the extra argument
approach does not allow for that.
Regards,
Maciej
P.S. I encourage further feedback to be sent to public-webapps for
those who are willing.
Mike
On Thu, Oct 2, 2008 at 6:07 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote:
On a separate thread, it was discussed that it is useful to support
microsecond resolution for future proofness.
I proposed seconds so that it was more clear that fractional
versions could be used, and because specifying microseconds as
fractional milliseconds seems awkward to me. But whatever the
baseline resolution, I think fractional values should be supported
so there isn't an artificial floor to the resolution on future
hardware.
- Maciej
-Darin
On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher
[EMAIL PROTECTED] wrote:
Why double delayInSeconds and not milliseconds to stay consistent?
On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:
On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I don't really like the overengineered version. I like the fairly
minimalist version best, but is there anything from the
overengineered version that should be added to it?
I like the fairly minimalist version best as well.
The stop() method does seem a little lonely on the Timer interface
all
by itself.
If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.
+1. My ideal would be the following:
Timer startTimer(double delayInSeconds, bool repeating, Function
callback);
interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}
That would cover the majority of cases I've seen in real-world
javascript code. The argument for setDelay is wanting to be able
to tweak the delay on the fly (e.g. Google Page Creator has
autosave code that gets a response from the server with a longer
delay time when the server is overloaded).
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 3, 2008, at 11:01 AM, Chris Marrin wrote:
On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
Hi Maciej.
Cameron McCormack:
If possible, it would be nice if there could be some degree of
compatibility between this proposed API and the one in SVG Tiny
1.2:
http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
Maciej Stachowiak:
I considered that, but I don't like the fact that it makes the
common
zero-delay continuation callback case into three lines of code
instead
of one, for what I think is no practical benefit.
Justin’s proposed API seems to need four lines for that case:
var t = new Timer();
t.repeatCount = 1;
t.addEventListener('timercomplete', function() { … }, false);
t.start();
compared with the three for SVG’s timer:
var t = createTimer(0, -1);
t.addEventListener('SVGTimer', function() { … }, false);
t.start();
See my proposal on another thread, which makes this:
startTimer(0, false, function() { ... });
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the timer immediately, as in your example. Or you
could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I don't expect it to be a common use case to create a timer in one
place and stop it in another. That being said, you can do this with
the API as proposed:
var t = startTimer(0, false, function() { ... });
t.stop(); // now you have a set up but non-running timer
...
t.restart(); // now it's actually going
I think wanting the timer to start right away is the more common case,
so the API is biased in that direction rather than towards initially
not running timers.
etc.
And you could easily add animation or media API's for synchronization:
var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
var transition = window.getTransitionForElement(element, left);
transition.trigger(t);
...
element.style.left = 100px;
This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.
This doesn't seem very compelling to me. Why not:
element.addEventListener(transitionend, function ()
{ startTimer(1.76, false, funtion() { ... }, false); } );
Since what a timer is going to do is run script, it doesn't seem like
a major benefit to avoid running a tiny bit of script to start it.
Especially if you have to run script to set it up anyway.
- Maciej
-
~Chris
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
Hi Chris.
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the timer immediately, as in your example.
I think Maciej has made a convincing case that new Timer is a bit
too coy about the fact that the timer is actually starting.
Or you could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I like your suggestion of adding startOneShot (and
startRepeating?) to the API. I think it would improve clarity over
a bool parameter specifying whether the timer repeats.
To create a Timer that isn't scheduled to fire:
new Timer(...)
To create a Timer that is scheduled to fire:
new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)
It would be pretty unusual for a method like startOneShot or
startRepeating to return a value. I'm not sure if you indended that;
if not
Or, if we don't like constructors:
createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)
We could rename the restart() method to start() (with the same
semantics, or also taking a bool) and have both createTimer() and
startTimer() if we think this use case is very important. I don't
think the need for unstarted timers is very high. However, here's yet
another tricksy way to achieve the same thing:
var tSpec = [0, false, function() {...});
...
var t = startTimer.apply(window, tSpec);
I think setting up a Timer with the intent of not only starting it but
defining the timing parameters is extra useless, since then all it
represents is a function.
Regards,
Maciej
And you could easily add animation or media API's for
synchronization:
var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
var transition = window.getTransitionForElement(element, left);
transition.trigger(t);
...
element.style.left = 100px;
This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.
This would be really cool!
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org
On Oct 2, 2008, at 3:13 PM, Adam Roben wrote: Hi all- Earlier today I landed a patch to add a new, simplified patch review interface to bugs.webkit.org. Looks very cool. My suggestion: I think the Edit link should be scrapped or reduced to only the few things you can't do from Review Patch, to reduce confusion. Regards, Maciej For each patch attached to a bugs, there is a new Review Patch link: Picture 42.png Clicking it will take you to a simple page with the patch on top and a comment form on the bottom: Picture 43.png Let me know if you have any problems or ideas for improvement (or file a bug on bugs.webkit.org about it)! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org
On Oct 3, 2008, at 2:06 PM, Maciej Stachowiak wrote: My suggestion: I think the Edit link should be scrapped or reduced to only the few things you can't do from Review Patch, to reduce confusion. Related: There are edit links in both bug discussions and the review query that would be better if they led to Review Patch instead. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebCoreLocalizedStrings
I'm building a Win32 project that links to WebCore.lib and I'm getting some linker errors, for instance: Error1error LNK2001: unresolved external symbol class WebCore::String __cdecl WebCore::unknownFileSizeText(void) ([EMAIL PROTECTED] @@[EMAIL PROTECTED]@XZ)WebCore.lib All of them are coming from not finding methods in WebCoreLocalizedStrings. I see that in WebCoreLocalizedStrings it is calling LPCTSTR_UI_STRING, which is defined as: #define LPCTSTR_UI_STRING(string, comment) WebLocalizedLPCTSTRUTF8(LOCALIZABLE_STRINGS_BUNDLE(FRAMEWORK_NAME), string) I can not find, for instance, [EMAIL PROTECTED]@@[EMAIL PROTECTED]@XZ, in the library that WebCore generated, so my question is, do I need to compile WebCore telling it where to find the localized.strings file, do I need to compile my project to find the file, or is there something else I'm missing? Thanks much, ~/Jason Hullinger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Oct 3, 2008, at 10:36 AM, Peter Kasting wrote: On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood [EMAIL PROTECTED] wrote: I'd say define it as a minimum precision of 1ms, but browser manufacturers can define any precision they wish. OK, but that only pushes the problem space outward rather than solving it. Make CPUs 10x faster and then have one browser with a floor of 1 ms and one with 0.1 ms and you have the exact scenario we're in today. Someone writes a tight loop in the 1 ms browser, checks that it doesn't use too much CPU, and pushes the build, and the 0.1 ms browser gets hosed. I admit that this one worries me a bit. My proposed requirement was that 0 timers must be processed as soon as possible (on the next return to the event loop) and that besides that accuracy to at least 1ms should be provided, but more if possible. I think 0-delay timers are the most interesting use case and the most likely to be set to repeat as an author mistake. A repeating indefinite 0-delay timer will quite likely hose any browser supporting this API per spec, so it shouldn't be a source of future variance problems. I think the use cases for repeating timers with very small but nonzero delays will be pretty rare; I doubt many authors specifically want a 1ms indefinite repeat for instance. So I think the difference between 1ms and .1ms will be less likely to be a future issue. If we are worried, though, we could require a 1ms floor for repeating or nested timers after some number of repeats (some largeish number, like 100) if we judge that having a crazy-fast repeating timer indefinitely is unlikely to be a valid use. I recommend sending further feedback to public-webapps. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 3, 2008, at 1:48 PM, Maciej Stachowiak wrote:
On Oct 3, 2008, at 11:01 AM, Chris Marrin wrote:
On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
Hi Maciej.
Cameron McCormack:
If possible, it would be nice if there could be some degree of
compatibility between this proposed API and the one in SVG Tiny
1.2:
http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
Maciej Stachowiak:
I considered that, but I don't like the fact that it makes the
common
zero-delay continuation callback case into three lines of code
instead
of one, for what I think is no practical benefit.
Justin’s proposed API seems to need four lines for that case:
var t = new Timer();
t.repeatCount = 1;
t.addEventListener('timercomplete', function() { … }, false);
t.start();
compared with the three for SVG’s timer:
var t = createTimer(0, -1);
t.addEventListener('SVGTimer', function() { … }, false);
t.start();
See my proposal on another thread, which makes this:
startTimer(0, false, function() { ... });
I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:
var t = new Timer(0, false, function() { ...});
which would start the timer immediately, as in your example. Or you
could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I don't expect it to be a common use case to create a timer in one
place and stop it in another. That being said, you can do this with
the API as proposed:
var t = startTimer(0, false, function() { ... });
t.stop(); // now you have a set up but non-running timer
...
t.restart(); // now it's actually going
I think wanting the timer to start right away is the more common
case, so the API is biased in that direction rather than towards
initially not running timers.
I think the reason you don't see the pattern of deferred timer
triggering is because today you just can't do it. I think the use case
I described (triggering a timer on an animation or media event) will
be common if and when we have that ability.
In the above example, does the system guarantee that starting a timer
and immediately stopping it will not ever fire that timer? I can't
imagine that guarantee being possible, especially for very short (or
zero) duration timers. If an implementation chooses to queue up timer
events as soon as they time out (plus the optimization that zero
duration timers would immediately queue), they would have to dig into
that queue and rip out any timers that are stopped. And that might not
even be desirable in many cases. What should happen when a timer times
out while a JS function is running and you stop it? Should its event
still run. I'm sure there are many interesting race conditions
possible here.
It seems like you would avoid these issues if you could have a param
to startTimer (or a separate createTimer function) that prevented the
timer from starting in the first place.
-
~Chris
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
Hi Geoff, On Oct 3, 2008, at 9:04 PM, Geoffrey Garen wrote: Again, I'm wondering how many legitimate uses are there for short timeouts in background tabs/windows. In a background window: animation video For animation and video, is it necessary even in a completely obscured view? audio I only meant to discuss javascript here. Are authors spinning audio using javascript setTimeout (I ask naïvely)? work queues for database or other background processing I think this is another example where event listeners or another approach entirely would be more legitimate than using timers. Are you talking about using setTimout to repeatedly poll to find out if a worker is finished? If so, this is definitely not the type of use we should facilitate long-term for script timers. Again, exploring these questions may lead us to a need to define other events that can trigger scripts to run (rather than reliance on polling). something interesting the web hasn't invented yet Given the need to reign in the abuses I don't find this too compelling. We wouldn't be preventing innovations, just restricting those innovations to run in unburied web pages. To give you some context, Safari used to throttle plug-in timers for background windows. The result was that users would see randomly choppy content. I'm more referring to pages that are completely buried and obscured so pages with no need not run at all and users would have no way to know they are running choppy. In a background tab: audio Again is this being done with javascript? Anyway, I don't think it is much to ask of users that they keep tabs unburied to enable listening to the embedded audio (or otherwise for browsers to provide an interface to re-enable audio within those buried tabs). So authors and users do not already have any ingrained preconceptions that audio must play even if a tab is buried (and so need to tailor APIs for authors to micro-manage this). work queues for database or other background processing something interesting the web hasn't invented yet See above. Also note that protections for background windows and tabs wouldn't solve the majority of the problem we've seen in the wild, which is the *foreground* window going crazy in a single-tabbed browsing session. I feel completely the opposite about this. If a foreground window is going crazy, that's a problem but a visible problem that even a novice user may know how to correct (if it even needs correcting). However, finding one or a dozen background tabs (amidst tens or hundreds) where those tabs contain needlessly running timers (in both javascript and elsewhere) is a huge power drain and one whose impacts are difficult to access. For mobile users the problem is more obvious, but even for desktops, how much wasted energy goes into these cycles when repeated across millions (billions?) of processors world-wide (and then the air-conditioning that also goes into compensating for that needless heat generation)[1]? Take care, Rob [1]: A bit off-topic: say a processor pegged at 20w churns away at these wasteful web app cycles for 2 hours each day driving the processor from an average of 10% power consumption to 99% power consumption. That's 17.8 power dissipation dedicated just to the needless cycles or 35.6 w-h energy consumption per day. For one billion computers that's 17.8 thousand MW or 35.6 thousand MW-h per day or 9256 thousand MW-h per work year. Avoiding something like 17.8 thousand wasted MW power dissipation (and 9256 thousand MW-hours of energy) eliminates the need for dozens of nuclear / coal power reactors worldwide (or even dirtier peaker power plants). Considering a 1.341 pounds of CO2 per kilowatt-hour (the 1999 estimated rate so over-optimistic for world-wide electricity production) that's 12,412 pounds per year. At 10¢ a kw-h that's $925 million per year in world- wide electricity expenses. And that's without calculating compensating cooling power consumption, both internal and external to the computing device. There's a lot of power (and potential power wasted) in the hands of browser developers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On 3-Oct-08, at 3:01 AM, Cameron McCormack wrote: Hi Maciej. Cameron McCormack: If possible, it would be nice if there could be some degree of compatibility between this proposed API and the one in SVG Tiny 1.2: http://dev.w3.org/SVG/profiles/1.2T/publish/ svgudom.html#svg__SVGTimer Maciej Stachowiak: I considered that, but I don't like the fact that it makes the common zero-delay continuation callback case into three lines of code instead of one, for what I think is no practical benefit. Justin’s proposed API seems to need four lines for that case: var t = new Timer(); t.repeatCount = 1; Just curious - does that mean repeat once or fire once? Seems ambiguous on first glance. I like Maciej's simple proposal better. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote: I'm not opposed to any of this; and the new API is definitely nicer. I'll bring up a devil's advocate point. One thing I hate is the Microsoft-style smorgasboard of APIs. When you want to start a timer, you have 6 to choose from, and I hope we can avoid similar problems in the DOM. Minor philosophical digression that I thought of after the fact. One of the things I found most unpleasant about Win32 APIs compared to Mac OS X and other Unix-like systems is the fact that so many seemingly basic calls take so many parameters. And that many of the parameters are often structs filled with many mysterious fields, and pointers to other structs. That makes figuring out how to do even the most basic thing a mystery. On Mac OS X (from Cocoa to the BSD layer on down), this kind of parameteritis is rare, and the same is true of the Web platform. I find Cocoa development and Web development more fun than win32 development, and I think I am not alone in feeling that way. So I fear parameteritis more than multiple functions with similar effects. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] gjs and WebKit
Hello, Is it in plans to include gjs to WebKit? If it is, what would gjs look like in perspective? Will it be full GObject equivalent of JavaScriptCore API (contain GObject bindings of JSContextRef, JSObjectRef, et c.)? Or it won't differ much from current state? -- Best regards, Anton ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
