Re: [whatwg] Real-time thread support for workers
+1 Jonas. Though a bit off-topic. Robert's Audio (and by all obvious means, video/canvas/pixel) workers preserve this trust across all routes. Unfortunately for developers, there is a lacking trust with vendors in exposing low-level audio-visual-spatial-semantic APIs for sandboxed communication. (also off-topic). Summary: realtime threads existed and are spec'ed in a simple proposal. They're a specialized instance of web workers. Also, opinions exist about web apps and security. On Aug 11, 2012, at 8:48 PM, Jonas Sicking wrote: > On Sat, Aug 11, 2012 at 3:22 PM, Jussi Kalliokoski > wrote: >> On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard wrote: >> >>> On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski < >>> jussi.kallioko...@gmail.com> wrote: >>> On W3C AudioWG we're currently discussing the possibility of having web workers that run in a priority/RT thread. This would be highly useful for example to keep audio from glitching even under high CPU stress. >>> >>> Realtime work is hard in a nondeterministically GC'd environment. >>> >>> Be careful about a flag that says "run this thread at higher priority". >>> People will simply always set it; it makes their code run faster (at the >>> expense of other pages' workers, who they don't care about). >>> >> >> I'm not sure what that claim is based on, in native applications the >> process priority hardly ever (haven't seen once, actually) gets abused. The >> only place where high priority really makes sense outside the main thread >> (which we won't allow) is time-critical threads, such as audio processing >> or a physics engine. > > The security model for native applications is different from the > security model for the web. > > When running a native application on most contemporary operating > systems, you are trusting that application to behave well. I.e. you > trust it to not read private data from your computer and send it to a > remote location. You trust it to not use system resources to send spam > emails. You trust it to not install backdoors and hand control over > your computer to other people. > > This isn't generally true with web applications. People often end up > running web applications that they don't trust in the least. They just > clicked a link in an email or on a search result page. They still > expect none of the above things to happen, but not because the pages > that they end up on won't attempt to do it, but because the browser > will prevent any of the above from happening. > > / Jonas
Re: [whatwg] Real-time thread support for workers
On Sat, Aug 11, 2012 at 3:22 PM, Jussi Kalliokoski wrote: > On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard wrote: > >> On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski < >> jussi.kallioko...@gmail.com> wrote: >> >>> On W3C AudioWG we're currently discussing the possibility of having web >>> workers that run in a priority/RT thread. This would be highly useful for >>> example to keep audio from glitching even under high CPU stress. >>> >> >> Realtime work is hard in a nondeterministically GC'd environment. >> >> Be careful about a flag that says "run this thread at higher priority". >> People will simply always set it; it makes their code run faster (at the >> expense of other pages' workers, who they don't care about). >> > > I'm not sure what that claim is based on, in native applications the > process priority hardly ever (haven't seen once, actually) gets abused. The > only place where high priority really makes sense outside the main thread > (which we won't allow) is time-critical threads, such as audio processing > or a physics engine. The security model for native applications is different from the security model for the web. When running a native application on most contemporary operating systems, you are trusting that application to behave well. I.e. you trust it to not read private data from your computer and send it to a remote location. You trust it to not use system resources to send spam emails. You trust it to not install backdoors and hand control over your computer to other people. This isn't generally true with web applications. People often end up running web applications that they don't trust in the least. They just clicked a link in an email or on a search result page. They still expect none of the above things to happen, but not because the pages that they end up on won't attempt to do it, but because the browser will prevent any of the above from happening. / Jonas
[whatwg] Opera should fallback with scripting *disabled* (was Re: Wasn't there going to be a strict spec?)
Karl Dubost writes: > On top of that you can add a layer of madness with user-agent sniffing. I > have documented one we had in Opera > and forced us to recover automatically. *unfortunately*. Can this be done with scripting *disabled*? I am thinking that XHTML can be used as a defense-in-depth against XSS attacks in the future. Yuhong Bao
Re: [whatwg] Real-time thread support for workers
On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard wrote: > On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski < > jussi.kallioko...@gmail.com> wrote: > >> On W3C AudioWG we're currently discussing the possibility of having web >> workers that run in a priority/RT thread. This would be highly useful for >> example to keep audio from glitching even under high CPU stress. >> > > Realtime work is hard in a nondeterministically GC'd environment. > > Be careful about a flag that says "run this thread at higher priority". > People will simply always set it; it makes their code run faster (at the > expense of other pages' workers, who they don't care about). > I'm not sure what that claim is based on, in native applications the process priority hardly ever (haven't seen once, actually) gets abused. The only place where high priority really makes sense outside the main thread (which we won't allow) is time-critical threads, such as audio processing or a physics engine. > Once people start doing that, everyone has to do it. Limiting this to > audio threads probably won't help--people will spin up fake audio threads > in order to get higher priority for other work. > That's even less helpful, making the audio run in the thread will effectively counteract any benefits you might get from setting the priority higher. > Limiting the amount of work that can actually be done would probably help > this. For example, although you may be giving the thread a timeslice every > 10ms, the thread may only have 3ms to do its work and return before being > preempted. Audio output threads need to run regularly, but most don't > actually do a whole lot of work. > That depends on use cases, in modern games for example convolution is often used to simulate space and it's often very CPU-intensive. > Also, note that actual realtime threads in many OSs (including, last I > knew, both Windows and Linux) have the capacity to take all CPU and hang > the system. I suspect implementations would play it safe and go no higher > than "high priority", though you could probably do this safely with careful > CPU quotas. > That is correct, assuming a single-core system, otherwise you'll need more than one realtime thread. This is something that needs to be thought out thoroughly. If the UA has the control over the priority of the worker (as opposed to being a flag set by the developer), the UA can however monitor the CPU usage of the worker and lower the priority if needed (if the thread is using 100% CPU the audio is glitching anyway). > (These are all implementation details, of course.) > > Realtime processing is tricky natively; trying to do this in JS on the web > is probably a hard problem. > Not necessarily. Real time processing is hard natively because it imposes a different set of best practices such as avoiding blocking as much as possible. The web is by nature designed to be asynchronous and that's also the model adopted by web developers. If anything, the web is at least by API design a better place for real time processing. Cheers, Jussi
Re: [whatwg] Wasn't there going to be a strict spec?
Le 10 août 2012 à 20:19, Tab Atkins Jr. a écrit : > I don't wish to spend the time to dig up the studies showing that 95% or so > of XML served as text/html is invalid XML That doesn't really makes sense, but I guess what Tab meant is People attempting to write documents * with XML syntax rules (such as for example XHTML 1.0), * and serving it as text/html. Often, these documents are NOT well-formed, even before being valid, and even-less conformant. On top of that you can add a layer of madness with user-agent sniffing. I have documented one we had in Opera and forced us to recover automatically. *unfortunately*. It also makes the task of creating a survey very hard because… well you get different markup, redirections, etc. aka results because of the user agent sniffing. See [Wrong To Be Right - application/xhtml+xml][1] [1]: http://my.opera.com/karlcow/blog/2011/03/03/wrong-to-be-right-with-xhtml For stats, there are two big surveys which have been made in the past (maybe it is what Tab refers to) https://developers.google.com/webmasters/state-of-the-web/ http://dev.opera.com/articles/view/mama/ PS: Erik, you can also rely on XHTML5. Aka serving your document as application/xhtml+xml, expect issues with browser market shares in some countries. -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: [whatwg] Features for responsive Web design
Am 10.08.2012 12:06 schrieb Odin Hørthe Omdal: On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński wrote: One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). I don't see the big problem, I think the spec is fine here. Yes it allows for putting a float there, but authors won't use it, so what's the problem? The spec already say you should use the number to calculate the correct intrinsic size, and the implementation will know what to do with a float number there if someone finds an actual use for it. This isn't limiting it for the sake of making anything easier, it's not like "the x is an integer" is any easier than "the x is a float". And if you *do* somehow find a good use for it down the line (and I believe there might be, maybe 0.5x) it'll be there and work. No harm. :) One hypothetic use case for 0.5x could be: Future UAs may want to progressively load sources in order to display a lowres image very quickly, and increase quality if there is enough bandwidth to do so, similarly to what we know from interlaced GIFs. Authors then might want to provide 0.5x and even 0.25x sources for this purpose.
