Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 22, 2012, at 7:10 PM, Glenn Maynard wrote: On Sun, Apr 22, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote: All JavaScript that runs on the main thread has the potential to freeze the UI for all pages sharing that thread. APIs on the main thread are designed to allow developers to avoid doing just that. If the *only* way to do something has that potential, then it's a bug in the API. Some feel that a call that reads from the GPU may also be in this category of intrinsically too slow/unpredictable. However, we are talking about operations with a much lower upper bound on their execution time. If the reasonable upper bound is high enough to cause visible UI degradation, and an asynchronous API can prevent that, then it needs an asynchronous API. If adding an async version has not been an emergency so far, then I don't think it is critical enough to block adding scaled backing store support. I hope we doesn't need an emergency to fix problems. Nobody's proposing blocking anything, just providing a better API. This doesn't impose any requirements on implementations who don't need it; it just makes it possible for those who do. Those who don't can always block and queue the callback to happen as soon as the script returns to the event loop--doing it better is just QoI. For the record, I don't object to adding an async version of getImageData, or some alternate means of getting async behavior. I would, however, object to: - Removing the existing synchronous getImageData (too much compatibility impact at this point) - Forcing getImageDataHD to only offer an async variant, despite synchronous getImageData existing probably indefinitely At least the latter has been advocated previously on this thread. It's not clear to me what you are personally advocating, so I cannot tell if I disagree with you. Regards, Maciej
Re: [whatwg] Encoding Sniffing
On Sat, Apr 21, 2012 at 1:21 PM, Anne van Kesteren ann...@opera.com wrote: This morning I looked into what it would take to define Encoding Sniffing. http://wiki.whatwg.org/wiki/Encoding#Sniffing has links as to what I looked at (minus Opera internal). As far as I can tell Gecko has the most comprehensive approach and should not be too hard to define (though writing it all out correctly and clear will be some work). The Gecko notes aren't quite right: * The detector chosen from the UI is used for HTML and plain text when loading those in a browsing context from HTTP GET or from a non-http URL. (Not used for POST responses. Not used for XHR.) * The default for the UI setting depends on the locale. Most locales default to know detector at all. Only zh-TW defaults to the Universal detector. (I'm not sure why, but I think this is a bug of *some* kind. Perhaps the localizer wanted to detect both Traditional and Simplified Chinese encodings and we don't have a detector configuration for TraditionalSimplified.) Other locales that default to having a detector enabled default to a locale-specific detector (e.g. Japanese or Ukranian). * The Universal detector is used regardless of UI setting or locale when using the FileReader to read a local file as text. (I'm personally very unhappy about this sort of use of heuristics in a new feature.) * The Universal detector isn't really universal. In particular, it misdetects Central European encodings like ISO-8859-2. (I'm personally unhappy that we expose the Universal detector in the UI and thereby bait people to enable it.) * Regardless of detector setting, when loading HTML or plain text in a browsing context, Basic Latin encoded as UTF-16BE or UTF-16LE is detected. This detection is not performed by FileReader. I have some questions though: 1) Is this something we want to define and eventually implement the same way? I think yes in principle. In practice, it might be hard to get this done. E.g. in the case of Gecko, we'd need someone who has no higher priority work than rewriting chardet in compliance with the hypothetical spec. I don't want to enable heuristic detection for all HTML page loads. Yet, it seems that we can't get rid of it for e.g. the Japanese context. (It's so sad that the situation is the worst in places that have multiple encodings and, therefore, logically should be more aware of the need to declare which one is in use. Sigh.) I think it is bad that the Web-exposed behavior of the browser depends on the UI locale of the browser. I think it would be worthwhile research project to find out if that were feasible to trigger language-specific heuristic detection on a per TLD basis instead on a per UI locale basis (e.g. enabling the Japanese detector for all pages loaded from .jp and the Russian detector for all pages loaded from .ru regardless of UI locale and requiring .com Japanese or Russian sites to get their charset act together or maybe having a short list of popular special cases that don't use a country TLD but don't declare the encoding, either). 2) Does this need to apply outside HTML? For JavaScript it forbidden per the HTML standard at the moment. CSS and XML do not allow it either. Is it used for decoding text/plain at the moment? Detection is used for text/plain in Gecko when it would be used for text/html. I think detection shouldn't be used for anything except plain text and HTML being loaded into browsing context considering that we've managed this far without it (well, except for FileReader). (Note that when not declaring the encoding on their own JavaScript and CSS inherit the encoding of the HTML document that references them.) 3) Is there a limit to how many bytes we should look at? In Gecko, the Basic Latin encoded as UTF-16BE or UTF-16LE check is run on the first 1024 bytes. For the other heuristic detections, there is no limit and changing the encoding potentially causes renavigation to the page. During the Firefox for development cycle, there was a limit of 1024 bytes (no renavigation!), but it was removed in order to support the Japanese Planet Debian (site fixed since then) and other unspecified but rumored Japanese sites. On Sun, Apr 22, 2012 at 2:11 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: We've had some discussion on the usefulness of this in WebVTT - mostly just in relation with HTML, though I am sure that stand-alone video players that decode WebVTT would find it useful, too. WebVTT is a new format with no legacy. Instead of letting it become infected with heuristic detection, we should go the other direction and hardwire it as UTF-8 like we did with app cache manifests and JSON-in-XHR. No one should be creating new content in encodings other than UTF-8. Those who can't be bothered to use The Encoding deserve REPLACEMENT CHARACTERs. Heuristic detection is for unlabeled legacy content. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Encoding Sniffing
On 2012-04-23 10:19, Henri Sivonen wrote: ... * The Universal detector is used regardless of UI setting or locale when using the FileReader to read a local file as text. (I'm personally very unhappy about this sort of use of heuristics in a new feature.) ... +1 ... WebVTT is a new format with no legacy. Instead of letting it become infected with heuristic detection, we should go the other direction and hardwire it as UTF-8 like we did with app cache manifests and JSON-in-XHR. No one should be creating new content in encodings other than UTF-8. Those who can't be bothered to use The Encoding deserve REPLACEMENT CHARACTERs. Heuristic detection is for unlabeled legacy content. ... +1
Re: [whatwg] Readiness of script-created documents
On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] createTBody on the table element.
Hello everyone, I was looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#dom-table-createtbody and I wonder why it was added. For now none of the browsers seem to implement it. I proposed a patch for WebKit but I'm wondering why this method exists as you can do what it does with the regular DOM API. Is it convenience? It was added to be consistent with createTFoot and createTHead? Thanks. -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia
[whatwg] Proposal for readyState behavior
I propose we adopt the following rules:
1) Every document that's being built by a parser or being built by an
XSLT engine has loading as its readyState.
Rationale:
* This is intuitive.
* It makes sense to make the XSLT experience as similar as
possible to the parser experience to avoid weirdness and also because
in most browser the XSLT result going through the HTML parser.
* This is already true in Chrome, Opera and Firefox 14. (It's
not always true in older Firefox: document.open() forgets to change
readyState to loading in Firefox 14.)
Note: This is not true for trivial non-script-created documents
in IE 6 through 10 inclusive, but since all other engines get away
with not cloning IE's weirdness, it seems we don't need to clone it.
In all versions of IE 6 through 10 inclusive, it's possible for a
document to be in mid-parse but have interactive as its readyState.
It seems to me that complex cases (enough external resources not
already in cache) may change the behavior to a direction more similar
with other browsers, but now I fail to reproduce this.
Delta from the spec: Make this explicit for XSLT.
2) Every document that's no longer being parsed reaches readyState
complete as the event loop gets to spin.
Rationale:
* It's counter-intuitive for aborted documents to stay in the
loading state forever.
* This seems to be already true in Chrome, Opera and IE for
documents that have been being parsed at some point. (Curiously,
Firefox makes an effort to keep this false for Firefox!)
Delta from the spec: Aborted documents reach complete. Making
this explicit for XSLT.
3) No document transitions from loading to complete without an
intermediate interactive state.
Rationale:
* It's counter-intuitive and potentially bug-inducing for
special cases to skip the interactive state when the interactive
state occurs on the common path in Chrome, Opera and Firefox.
* Cases where this currently isn't true are so inconsistent
between browsers that I'm assuming they are bugs or intentional ad hoc
hacks that haven't been informed by broader research.
Delta from the spec: To the extent there's the above delta that
aborted documents reach complete, this is new. Making this explicit
for XSLT.
4) Whenever a transition to interactive is made, DOMContentLoaded
must eventually get fired later if the document stays in a state where
events can fire on it.
Rationale:
* This seems sensible for consistency with the common case.
Currently, there are cases where Firefox fires DOMContentLoaded
without a transition to interactive or transitions to interactive
without ever firing DOMContentLoaded, but these cases are inconsistent
with other browsers, so it's hard to believe they are well-considered
compatibility features.
Delta from the spec: Same as for point 3.
5) window.stop() aborts the parser.
Rationale:
* Already true in Firefox and Chrome.
* document.execCommand('Stop') is the closest equivalent in IE
and it aborts the parser when loading from network (not in the
document.open() case, though!)
Delta from the spec: Currently, the spec cancels navigation
instead of aborting the parser.
6) The load event doesn't fire for documents whose parser has been aborted.
Rationale:
* Already true in Firefox, Chrome and IE. (I don't know of a
way to abort the parser in Opera from JS without side effects that'd
interfere with testing.)
Delta from the spec: If the end part of the parse starts running
on abort, load can't fire as an unconditional part of the end.
7) The load event shouldn't fire synchronously.
Rationale:
* Events that sometimes fire synchronously and sometimes
asynchronously are trouble.
* Already true in Opera and Firefox. (But not in Chrome and IE9!)
Delta from the spec: No delta.
8) When readyState changes, a readystatechange should be fired
(synchronously immediately after readyState changed)
Rationale:
* Seems illogical not to.
* Already true in Chrome and Firefox, so it seems browsers can
get away with doing the logical thing.
Delta from the spec: No delta.
9) Never fire readystatechange so that the old and new readyState
are the same.
Rationale:
* Logic.
* All deviations from this rule look like browser-specific bugs.
Delta from the spec: No delta.
10) XSLT error pages don't count as aborts but instead as non-aborted
loads of the error page.
Rationale:
* Makes parent pages less confused about events they are waiting.
* Already true except for bugs in Firefox which is the only
browser with XSLT error pages.
Delta from the spec: Make explicit in spec.
Aside: Might make sense to spec DOMFrameContentLoaded. Firefox and
Opera support it.
Demos of interest:
http://hsivonen.iki.fi/test/moz/readystate/
IE can go to interactive prematurely:
http://hsivonen.iki.fi/test/moz/readystate/baseline.html
Re: [whatwg] createTBody on the table element.
On Mon, 23 Apr 2012, Alexis Menard wrote: I was looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#dom-table-createtbody and I wonder why it was added. For now none of the browsers seem to implement it. I proposed a patch for WebKit but I'm wondering why this method exists as you can do what it does with the regular DOM API. Is it convenience? It was added to be consistent with createTFoot and createTHead? Consistency and convenience, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createTBody on the table element.
On Mon, Apr 23, 2012 at 1:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 23 Apr 2012, Alexis Menard wrote: I was looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#dom-table-createtbody and I wonder why it was added. For now none of the browsers seem to implement it. I proposed a patch for WebKit but I'm wondering why this method exists as you can do what it does with the regular DOM API. Is it convenience? It was added to be consistent with createTFoot and createTHead? Consistency and convenience, yes. So we should implement it. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia
[whatwg] [Canvas] Text height
The measureText method in canvas' 2d context only returns the width of a span of text. Why not the height? I understand the desire to keep text rendering simple but for people that want to expand on this even a little bit needing to work around not having access to the height only complicates the simplicity of the whole thing. Already included in the canvas context is the ability to set the context.textBaseline, this is actually a rather advanced feature I would think but the problem is that if you are changing it from the default and filling text at 0,0 the text will be rendered off the screen. To figure out the position that the text needs to be rendered to get it back on the screen with a textBaseline as 'alphabetic' you would need the height of the text I would think? Also if you are rendering a few lines of text, you would want to know the height of the last line to know where the next line should be rendered. Early versions of Bespin used the width of a 'm' character to guess at what the height of all characters would be. This is far to obscure for the standard user to figure out or even have an understanding why in my mind. But that trick doesn't work with fonts that don't have standard proportions. I have seen other far more complicated ways to get at the same information but how about just adding height to the measureText method? Here are some post around the internet of people complicating things to get at this information http://stackoverflow.com/questions/1134586/how-can-you-find-the-height-of-text-on-an-html-canvas http://www.html5rocks.com/en/tutorials/canvas/texteffects/#toc-text-shadow-clipping http://mudcu.be/journal/2011/01/html5-typographic-metrics/#measure This is my first post to this list, I'm sorry if this isn't formatted the way proposals should be. I'm happy to include more information or examples if needed. I have other ideas to add but I thought I would start here, one property at a time. Thanks, Tyler Larson
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Tue, Apr 17, 2012 at 9:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/12 6:32 PM, Darin Fisher wrote: In Chrome at least, getImageData() doesn't actually block to fetch pixels. The thread is only blocked when the first dereference of the pixel buffer occurs. How does that interact with paints that happen after the getImageData call? Or is the point that you send off an async request for a pixel snapshot but don't block on it returning until someone tries to reach into the pixel buffer? To answer your second question: Yes. I think the implication for the first question is that you would get back a snapshot of what the pixel data should have been when you called getImageData. -Darin
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Sun, Apr 22, 2012 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2012, at 6:53 AM, Glenn Maynard wrote:
On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak m...@apple.com wrote:
You could also address this by adding a way to be notified when the
contents of an ImageData are available without blocking. That would work
with both vanilla getImageData and the proposed getImageDataHD. It would
also give the author the alternative of just blocking (e.g. if they know
the buffer is small) or of sending the data off to a worker for processing.
This would result in people writing poor code, based on incorrect
assumptions. It doesn't matter how big the buffer is; all that matters is
how long the drawing calls before the getImageData take. For example, if
multiple canvases are being drawn to (eg. on other pages running in the
same thread), they may share a single drawing queue.
Any time you retrieve image data synchronously, and it happens to require
a draw flush, you freeze the UI for all pages sharing that thread. Why is
that okay for people to do? We should know better by now than to expose
APIs that encourage people to block the UI thread, after spending so much
time trying to fix that mistake in early APIs.
(This should expose a synchronous API in workers if and when Canvas makes
it there, of course, just like all other APIs.)
All JavaScript that runs on the main thread has the potential to freeze
the UI for all pages sharing that thread. One can imagine models that
avoid this by design - for example, running all JavaScript on one or more
threads separate from the UI thread. But from where we are today, it's not
practical to apply such a solution. It's also not practical to make every
API asynchronous - it's just too hard to code that way.
In light of this, we need some sort of rule for what types of APIs should
only be offered in asynchronous form on the main thread. Among the major
browser vendors, there seems to be a consensus that this should at least
include APIs that do any network or disk I/O. Network and disk are slow
enough and unpredictable enough that an author could never correctly judge
that it's safe to do synchronous I/O.
Some feel that a call that reads from the GPU may also be in this category
of intrinsically too slow/unpredictable. However, we are talking about
operations with a much lower upper bound on their execution time. We're
also talking about an operation that has existed in its synchronous form
(getImageData) for several years, and we don't have evidence of the types
of severe problems that, for instance, synchronous XHR has been known to
cause. Indeed, the amount of trouble caused is low enough that no one has
yet proposed or implemented an async version of this API.
The point is not about whether the jank introduced by GPU readbacks is
emergency level. The point is that it can be costly, and it can interfere
greatly with having an interactive main thread. If you assume a goal of 60
FPS, then smallish jank can be killer. It is common for new GL programmers
to call glGetError too often for example, and that can kill the performance
of the app. Of course this is no where near as bad as synchronous XHR. It
doesn't have to be at that level to be a problem. I think it is fair to
focus on 60 FPS as a goal in other words.
That said, I've come around to being OK with getImageDataHD. As I wrote
recently, this is because it is possible to implement that in a
non-blocking fashion. It can just queue up a readback. It only becomes
necessary to block the calling thread when a pixel is dereferenced. This
affords developers with an opportunity to instead pass the ImageData off to
a web worker before dereferencing. Hence, the main thread should not jank
up. This of course requires developers to be very smart about what they
are doing, and for browsers to be smart too.
I'm still sad that getImageData{HD} makes it easy for bad code in one web
page to screw over other web pages. The argument that this is easy to do
anyways with long running script is a cop out. We should guide developers
to do the right thing in this cooperatively multi-tasking system.
-Darin
If adding an async version has not been an emergency so far, then I don't
think it is critical enough to block adding scaled backing store support.
Nor am I convinced that we need to deprecate or phase out the synchronous
version. Perhaps future evidence will change the picture, but that's how it
looks to me so far.
Regards,
Maciej
Re: [whatwg] Encoding Sniffing
21.04.2012, в 3:21, Anne van Kesteren написал(а): 1) Is this something we want to define and eventually implement the same way? I think that the general direction should be getting rid of encoding sniffing. It's very rarely helpful if ever, and implementations are wildly different. WebKit can optionally use ICU for charset detection. We also have custom built-in heuristics to switch between Japanese encodings only (think rendering unlabeled EUC-JP pages when default browser encoding is set to Shift-JIS). Safari doesn't enable ICU based detection to no visible user disconcert, and I don't know if the Japanese heuristics are still important. 2) Does this need to apply outside HTML? For JavaScript it forbidden per the HTML standard at the moment. CSS and XML do not allow it either. Is it used for decoding text/plain at the moment? 3) Is there a limit to how many bytes we should look at? Related to the last question, WebKit doesn't implement re-navigation (neither for charset sniffing, nor for meta charset), and I don't think that we ever should. - WBR, Alexey Proskuryakov
[whatwg] [canvas] matrix based changes on bitmaps
Can we add matrix transformations? Looping over every pixel in JavaScript is slow. Many cool things could be taken care of much faster if the canvas had some form of matrix manipulations built in. All of the pixels could have one transformation operation defined and all of the pixels could be operated on at once in something lower level. It could look like this... context.transformMatrix([0.5,0.5,0.5,0,0, 0.5,0.5,0.5,0,0, 0.5,0.5,0.5,0,0, 0,0,0,1,0, 0,0,0,0,1]); It's far simpler than looping over an array of pixels and picking out the values of each color. Other graphics systems have ways of doing this already. You can easily find sample tutorials on how to create and transform matrixes. In some languages they have matrix objects that have methods for even easier manipulation of these transformations but I'm cool without this if it is easier. -Tyler Larson
[whatwg] Administrivia
Last year the W3C introduced a new framework for people developing specifications, which they call Community Groups (CGs). Since then we have moved a few parts of the HTML standard under CGs, most notably Aryeh's HTML Editing APIs specification [1], which replaced the old execCommand() spec in the HTML standard. The main advantage of doing this is that it means we have a clear patent policy. Historically, we've relied on the W3C HTML working group for this, but as the W3C has focused on stablising their HTML5 snapshot, newer features have not enjoyed the same coverage. To address this, today I have started the process of forming a community group for the rest of the WHATWG work. This will basically have no effect on how the WHATWG operates, except that when we make use of the W3C Community Group Final Specification Agreement (FSA) mechanism, anyone who wishes to co-sign the agreement [2] will be invited to do so. [1] http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [2] http://www.w3.org/community/about/agreements/final/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] matrix based changes on bitmaps
On 4/23/2012 2:38 PM, Tyler Larson wrote:
Can we add matrix transformations?
Looping over every pixel in JavaScript is slow. Many cool things could be taken
care of much faster if the canvas had some form of matrix manipulations built
in.
All of the pixels could have one transformation operation defined and all of
the pixels could be operated on at once in something lower level.
It could look like this...
context.transformMatrix([0.5,0.5,0.5,0,0,
0.5,0.5,0.5,0,0,
0.5,0.5,0.5,0,0,
0,0,0,1,0,
0,0,0,0,1]);
It's far simpler than looping over an array of pixels and picking out the
values of each color.
Other graphics systems have ways of doing this already. You can easily find
sample tutorials on how to create and transform matrixes.
In some languages they have matrix objects that have methods for even easier
manipulation of these transformations but I'm cool without this if it is easier.
WebKit recently landed Uint8ClampedArray. That brings us all in line
with Typed Arrays.
Currently, if you want to do fast operations on a Canvas, you need to
load it into WebGL and use GLSL to do your quick vector math.
It'd be nice to see a math object for Typed Arrays with similar power.
When we implemented Canvas independently (prior to WebGL publication),
we simply stuck filters onto the ImageData object.
such as ImageData.blur().
But, directly addressing your example, I could see something like:
var a = new MatrixMath();
var b = ctx.getImageData(0,0,200,200);
a.mulAdd(b.width, b.height, b.data, [0.5,0.5,0.5,0,0,
0.5,0.5,0.5,0,0,
0.5,0.5,0.5,0,0,
0,0,0,1,0,
0,0,0,0,1]);
a.process(function() { ctx.putImageData(a,0,0); });
Re: [whatwg] [canvas] matrix based changes on bitmaps
On 4/23/12 5:57 PM, Charles Pritchard wrote: Currently, if you want to do fast operations on a Canvas, you need to load it into WebGL and use GLSL to do your quick vector math. It'd be nice to see a math object for Typed Arrays with similar power. http://software.intel.com/en-us/articles/opencl-river-trail/ is worth looking at in this context. -Boris
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 23, 2012 at 12:43 PM, Darin Fisher da...@chromium.org wrote: That said, I've come around to being OK with getImageDataHD. As I wrote recently, this is because it is possible to implement that in a non-blocking fashion. It can just queue up a readback. It only becomes necessary to block the calling thread when a pixel is dereferenced. This affords developers with an opportunity to instead pass the ImageData off to a web worker before dereferencing. Hence, the main thread should not jank up. This of course requires developers to be very smart about what they are doing, and for browsers to be smart too. It's reasonable to expect users to use async APIs in the main thread; that's just a part of the platform. It's not reasonable to expect people to fire up a worker and transfer the buffer to the worker to prevent the blocking from happening in the main thread. That's a particularly hackish workaround, not a replacement for an async API. -- Glenn Maynard
Re: [whatwg] [canvas] matrix based changes on bitmaps
On 4/23/2012 6:18 PM, Boris Zbarsky wrote:
On 4/23/12 5:57 PM, Charles Pritchard wrote:
Currently, if you want to do fast operations on a Canvas, you need to
load it into WebGL and use GLSL to do your quick vector math.
It'd be nice to see a math object for Typed Arrays with similar power.
http://software.intel.com/en-us/articles/opencl-river-trail/ is worth
looking at in this context.
-Boris
Neither introduce multiply/add methods. They do improve on typical JS
methods.
http://cloud.github.com/downloads/RiverTrail/RiverTrail/rivertrail-api-draft-02-2012.pdf
https://github.com/sheremetyev/w16
Example from RiverTrail:
var myPA = new ParallelArray([1.0, 2.0, 3,0]); // 1.0, 2.0, 3.0
var myPlusPA = myPA(function(element){return element+1;}; // 2.0, 3.0,
4.0 [sic]
The partition method (for map):
pa = new ParallelArray([1,2,3,4]) // 1,2,3,4
pa.partition(2)// 1,2,3,4
W16 looks a little more like typical processing, chunked into batches.
https://github.com/sheremetyev/w16/blob/master/w16/primes.js
ParallelArray(TypedArray) seems ok; it'd be nice though to have methods
on that object, instead of relying on callbacks.
Seems like convolution would go something like this:
var d = ctx.getImageData(0,0,ctx.width,ctx.height);
var pa = new ParallelArray(new Float32Array(d.data));
pa.partition(d.width);
pa.combine(2,function(y,i) {
this[y][i] = this[y][i-1]... etc;
});
It's just that our methods are typically in a for loop, such as the W16
primes.js example.
We'd probably end up with something like this instead of the cleaner
combine:
if(pa.isReal) { pa.batchSize = 1; pa.stride = 1; }
else { pa.batchSize = d.height; pa.stride = d.width; }
pa.combine(2, function(y,i) {
for(var height=pa.batchSize,width=pa.stride; yheight y++) for(;
iwidth; i++) { var offset = y * width;
this[offset + i] = this[offset + (i-1)]... etc;
}});
The for loop could be optimized out for items like RiverTrail, W16 could
use batchSize for its own batch semantics, typical polyfill/JS
implementations would just run apply or call.
It'd be nice to have progress events:
pa.onprogressevent = function() {
if(!e.readyState) console.log(processing);
if(e.readyState == 4) {
ctx.putImageData(d.data,0,0);
}
else {
console.log(.);
}
};
And it'd be nice to have basic matrix operations anyway. I'd like to see
mul and add. I've tried to abuse CSSMatrix for that purpose. It works,
but it's slow and not really intended for that purpose. It could be sped
up, if nothing else comes up.
-Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 4/23/2012 6:50 PM, Glenn Maynard wrote:
On Mon, Apr 23, 2012 at 12:43 PM, Darin Fisherda...@chromium.org wrote:
That said, I've come around to being OK with getImageDataHD. As I wrote
recently, this is because it is possible to implement that in a
non-blocking fashion. It can just queue up a readback. It only becomes
necessary to block the calling thread when a pixel is dereferenced. This
affords developers with an opportunity to instead pass the ImageData off to
a web worker before dereferencing. Hence, the main thread should not jank
up. This of course requires developers to be very smart about what they
are doing, and for browsers to be smart too.
It's reasonable to expect users to use async APIs in the main thread;
that's just a part of the platform. It's not reasonable to expect people
to fire up a worker and transfer the buffer to the worker to prevent the
blocking from happening in the main thread. That's a particularly hackish
workaround, not a replacement for an async API.
Looks like Maciej wants this one in ASAP as a synchronous method.
Dev's are still going to jank up their main thread when working with
getImageDataHD.
As a couple here have stated -- there's a lot more data with an HD layer.
Processing filters on the main thread has always been a UI blocker.
Here's a +1 to allowing
worker.postMessage(document.getCSSCanvasContext('2d','layer','1','1'))
in web workers.
It's completely non-standard but lets us all off the hook.
-Charles
Re: [whatwg] IBM864 mapping of Encoding Standard
(2012/04/20 17:09), Anne van Kesteren wrote: On Fri, 20 Apr 2012 09:58:52 +0200, Makoto Kato m_k...@ga2.so-net.ne.jp wrote: I have a question of Encoding standard of http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html. Gecko supports IBM864, but it is different of old IBM864. It is modified to support euro sign due to requested by IBM ([1] and [2]). Gecko also supports data:text/html;charset=ibm864,%25 0x25 - U+066A which is probably worse as it changes the ASCII range. You submit encoding detail [3] in repository, but this spec seems to be old spec of IBM864. I think that we should use new mapping supported euro sign [4] instead of old mapping. Or we should remove IBM code pages from spec. How do you think? Does that mean you want to remove the encoding from Gecko? That would work for me. It is currently not supported by Opera either. Alternatively mapping 0xA7 to U+20AC works for me too, but I don't want it to tinker with the ASCII range. Except to OS/2 and AIX, I think that this encoding is unnecessary since most browsers aren't supported. If you only add IBM864 and IBM866 to this spec as legacy encoding, you should add all encodings that Gecko supports due to ambiguous.
