Re: [whatwg] Canvas pixel manipulation and performance
On Dec 4, 2009, at 6:10 PM, Kenneth Russell wrote: > I think you'd get more traction if you had performance measurements; > minimally, profiles showing that this is hot in your current > application. Ideally, you could do a prototype in one of the browsers > supporting WebGL which exposes the ImageData's backing store as a > WebGLUnsignedIntArray. If this showed a significant speedup it would > provide strong motivation. My current application isn't necessarily the best test bed. I'll see what I can do to prototype it with some minimal test cases, though. Thanks for the suggestion. Jay
Re: [whatwg] Canvas pixel manipulation and performance
On Fri, Dec 4, 2009 at 9:30 AM, Jason Oster wrote: > I guess this suggestion to access the full pixel data in a single array > element has fallen by the wayside. Are there any direct objections to > including additional API to allow this kind of behavior? It seems most > developers believe it would be unnecessary, but I haven't heard much in the > way of reasoning (technical nor personal). > > I cannot comment on the "typical uses" of accessing pixel data from script; > if it is [in general] more important to have each of the R,G,B,A components > separated for script access, or not. But for cases involving indexed > palettes, having the ability to directly treat each pixel as a single > property is very much desired. > > It is not going to provide a huge boost in performance. At worst, it will > help make code cleaner. But at best, it will do that and [slightly?] reduce > the performance penalty of reading/writing 3 superfluous (in my eyes) array > accesses. The only negative aspect I can think of with additional API > functions is the introduction of new developer confusion; "Which one do I > use?" I think you'd get more traction if you had performance measurements; minimally, profiles showing that this is hot in your current application. Ideally, you could do a prototype in one of the browsers supporting WebGL which exposes the ImageData's backing store as a WebGLUnsignedIntArray. If this showed a significant speedup it would provide strong motivation. -Ken
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
On 04.12.2009, at 14:30, Jonas Sicking wrote: However for the events that are fired as a result of network activity, I see no reason to fire these events asynchronously from that code. Sounds like we're in complete agreement here. I've missed the change from sync to async dispatch when it was made in XHR specs (both v1 and v2), and I think that it should be reverted. - WBR, Alexey Proskuryakov
[whatwg] and 307 redirects
The spec lets sites submit forms with PUT or DELETE methods to their origin server. What happens if the server responds with a 307 redirect to a foreign origin? Based on my reading of the fetch algorithm, the browser will issue a PUT or DELETE request (respectively) to the foreign origin. It seems like we want to generate a network error instead. Adam
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
On Fri, Dec 4, 2009 at 9:52 AM, Alexey Proskuryakov wrote:
>
> On 04.12.2009, at 4:12, Anne van Kesteren wrote:
>
>>> On the other hand, it can't possibly work like XMLHttpRequest - for
>>> whatever reason, the Web Sockets spec says that events are posted
>>> asynchronously. Maybe I'm not the last an only one to get confused by this
>>> difference from XMLHttpRequest events.
>>
>> XMLHttpRequest network events are "asynchronous" too.
>
>
> Looks like the spec says so now. Does any browser post XMLHttpRequest events
> asynchronously? This change in the spec is not harmless, as it seems to make
> readystatechange event pretty much useless.
Depends which events we are talking about. Events that are fired as a
result of network activity is inheritly asynchronous since network
events arrive asynchronously. For example "progress" events or "load"
events.
Other events must be synchronous, for example the "readystatechange"
event that is fired during the call to XMLHttpRequest.open, or the
"loadstart" event fired from XMLHttpRequest.send must be fired
synchronously.
However for the events that are fired as a result of network activity,
I see no reason to fire these events asynchronously from that code.
I.e. when a network request is finished, XMLHttpRequest takes several
actions:
* Sets readystate to 4
* Fires "readystatechange"
* Fires "load"
* Fires "loadend"
* Makes responseXML non-null
I see no reason to make these events be fired asynchronously *from the
code that takes all these actions*. In other words, I think the
XMLHttpRequest implementation should look something like:
XMLHttpRequest::OnRequestDone(status) {
if (status != success) {
... error handling ...
return;
}
if (isXMLContentType(contentType)) {
responseXML = parseAsXML(responseText);
}
readystate = 4;
synchronousDispatch("readystatechange");
synchronousDispatch("load");
synchronousDispatch("loadend");
}
Another way to look at it is that I think the following code:
xhr = new XMLHttpRequest;
timerId = setInterval(function() { if(xhr.responseXML)
alert(xhr.responseXML); }, 0);
xhr.open(...);
xhr.send();
xhr.onloadend = function() {
cancelInterval(timerId);
}
should never ever fire the alert.
The whole purpose of firing events asynchronously is to aid
implementations so that they don't need to have a deep callstack when
the event fires, but instead can ensure to be in a stable state when
firing the event. However if the code in question is already started
asynchronously, such as as a result of a network event, then there is
no reason not to fire synchronously.
Firing events asynchronously always introduces hassles. Typically that
conditions change between when the event was scheduled to be fired,
and when the event actually fires. Many times this means that you have
to keep track of the task that will fire the event and under certain
conditions cancel it if what the event indicates is no longer true.
Thus I think we should as a general rule try to fire synchronously
when this doesn't risk destabilizing implementations.
/ Jonas
Re: [whatwg] Application cache updating synchronicity
My interpretation of this is that "atomically" is not to be read as "synchronously" with regard to tag parsing (which ultimately initiates the update algorithm). Otherwise step 1 could leave a blank page on the screen indefinitely (which is not the intent afaict). A clarification in the spec would help. Even in the absence of async user-interactions alluded to by step 1, allowing for async'ness at this point is beneficial since initial page loading can make progress w/o having to consult the appcache prior to getting past the tag. On Fri, Dec 4, 2009 at 2:01 PM, Alexey Proskuryakov wrote: > Recently, a new step was prepended to the application cache update > algorithm: > > "1. Optionally, wait until the permission to start the application cache > download process has been obtained from the user and until the user agent is > confident that the network is available. This could include doing nothing > until the user explicitly opts-in to caching the site, or could involve > prompting the user for permission. The algorithm might never get past this > point. (This step is particularly intended to be used by user agents running > on severely space-constrained devices or in highly privacy-sensitive > environments)." > > It's not clear if it's supposed to synchronous or not. The "doing nothing" > clause suggests that page loading can continue normally. On the other hand, > the algorithm says that asynchronous processing only begins after step 2, > which runs "atomically". > > - WBR, Alexey Proskuryakov > >
[whatwg] Application cache updating synchronicity
Recently, a new step was prepended to the application cache update algorithm: "1. Optionally, wait until the permission to start the application cache download process has been obtained from the user and until the user agent is confident that the network is available. This could include doing nothing until the user explicitly opts-in to caching the site, or could involve prompting the user for permission. The algorithm might never get past this point. (This step is particularly intended to be used by user agents running on severely space- constrained devices or in highly privacy-sensitive environments)." It's not clear if it's supposed to synchronous or not. The "doing nothing" clause suggests that page loading can continue normally. On the other hand, the algorithm says that asynchronous processing only begins after step 2, which runs "atomically". - WBR, Alexey Proskuryakov
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
On 03.12.2009, at 18:07, Ian Hickson wrote: I could change the spec to make the readyState attribute changes be queued along with the event dispatch, I do not understand why the events are queued, to begin with. Synchronous dispatch seems more useful to authors, as it gives more guarantees about connection state when handling the event. Implementations have always dealt with the necessary book-keeping to present asynchronous networking events in a synchronous manner, and I don't think think it's been a problem. An implementation that keeps parts of WebSocket logic in a different thread or process will need to queue readyState event changes as you describe, but that will be an implementation detail. but then we'd have a situation whereby the "actual" state of the websocket object might not match the state returned by the attribute. This doesn't sounds like an issue to me. The "actual" state is always out of sync, because client and server have different ideas of actual state. So does an Ethernet controller, OS interrupt handler, low level OS networking code, etc. The only state that matters client-side is what JavaScript code sees, and all the intermediaries must (and do) act as if that were the real thing. - WBR, Alexey Proskuryakov
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
On 04.12.2009, at 4:12, Anne van Kesteren wrote: On the other hand, it can't possibly work like XMLHttpRequest - for whatever reason, the Web Sockets spec says that events are posted asynchronously. Maybe I'm not the last an only one to get confused by this difference from XMLHttpRequest events. XMLHttpRequest network events are "asynchronous" too. Looks like the spec says so now. Does any browser post XMLHttpRequest events asynchronously? This change in the spec is not harmless, as it seems to make readystatechange event pretty much useless. - WBR, Alexey Proskuryakov
Re: [whatwg] Canvas pixel manipulation and performance
I guess this suggestion to access the full pixel data in a single array element has fallen by the wayside. Are there any direct objections to including additional API to allow this kind of behavior? It seems most developers believe it would be unnecessary, but I haven't heard much in the way of reasoning (technical nor personal). I cannot comment on the "typical uses" of accessing pixel data from script; if it is [in general] more important to have each of the R,G,B,A components separated for script access, or not. But for cases involving indexed palettes, having the ability to directly treat each pixel as a single property is very much desired. It is not going to provide a huge boost in performance. At worst, it will help make code cleaner. But at best, it will do that and [slightly?] reduce the performance penalty of reading/writing 3 superfluous (in my eyes) array accesses. The only negative aspect I can think of with additional API functions is the introduction of new developer confusion; "Which one do I use?" Thanks for listening, Jay
Re: [whatwg] Web API for speech recognition and synthesis
Indeed the API should be something significantly simpler than X+V. Microsoft has (had?) support for SALT. That API is pretty simple and provides speech recognition and TTS. The API could be probably even simpler than SALT. IIRC, there was an extension for Firefox to support SALT (well, there was also an extension to support X+V). If the platform/OS provides ASR and TTS, adding a JS API for it should be pretty simple. X+V tries to handle some logic using VoiceXML FIA, but I think it would be more web-like to give pure JS API (similar to SALT). Integrating visual and voice input could be done in scripts. I'd assume there would be some script libraries to handle multimodal input integration - especially if there will be touch and gestures events too etc. (Classic multimodal map applications will become possible in web.) But this all is something which should be possibly designed in or with W3C multimodal working group. I know their current architecture is way more complex, but X+X, SALT and even Multimodal-CSS has been discussed in that working group. -Olli On 12/3/09 2:50 AM, Dave Burke wrote: We're envisaging a simpler programmatic API that looks familiar to the modern Web developer but one which avoids the legacy of dialog system languages. Dave On Wed, Dec 2, 2009 at 7:25 PM, João Eiras mailto:jo...@opera.com>> wrote: On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert mailto:bring...@google.com>> wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] US-ASCII vs. ASCII in Web Socket Protocol
Hmmm... Maybe it would be better to say ISO-646US rather than ASCII. There is a lot of impreciseness about the very low value characters (less than 0x20 space) in the ASCII "specifications." The same can be said about the higher end. === Ian Hickson wrote: On Fri, 6 Nov 2009, Yuzo Fujishima wrote: I see both "US-ASCII" and "ASCII" are used in: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 If they mean the same thing, one should be used consistently. In the document, US-ASCII seems to mean encoding while ASCII mean charset. Is this common? (I guess US-ASCII is commonly considered as an alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases ) I've changed the spec to use "ASCII" consistently. Cheers,
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
On Thu, 03 Dec 2009 22:43:10 +0100, Alexey Proskuryakov wrote: On the other hand, it can't possibly work like XMLHttpRequest - for whatever reason, the Web Sockets spec says that events are posted asynchronously. Maybe I'm not the last an only one to get confused by this difference from XMLHttpRequest events. XMLHttpRequest network events are "asynchronous" too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Sockets URL
On Fri, 4 Dec 2009, Fumitoshi Ukai (��~\飼�~V~G�~U~O) wrote:
> On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson wrote:
> > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote:
> > >
> > > Currently, the Web Sockets API spec says that the WebSocket.URL
> > > attribute must just return a value that was passed to the WebSocket
> > > constructor. This doesn't match how many other url accessors work,
> > > and consequentially, it doesn't match what currently happens in
> > > WebKit.
> > >
> > > I think it makes more sense to return a resolved URL - e.g. (new
> > > WebSocket("ws://host/path/../")).URL would return "ws://host/".
> >
> > I've changed the spec to say that the .URL attribute must return the
> > same string as is actually used by the protocol spec (i.e.
> > post-resolve). Whether this does "../" resolution will depend on what
> > the IRI specs end up saying when we switch to relying on those.
>
> Should (new WebSocket("ws://host/path#frag")).URL be "ws://host/path"
> rather than "ws://host/path#frag" ? It seems "Resolving Web addresses"
> will drop fragment component according to
> http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it.
I hadn't considered #fragment components. I've changed the spec to say
that the constructor will throw an exception if one is present. ws: and
wss: URLs can't have fragment identifiers in this version of the protocol.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
