Re: [whatwg] onclose events for MessagePort
On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari eh...@mozilla.com wrote: Does navigation disentangle ports? I don't think it necessarily does, at least per spec. The current spec doesn't mention what happens in the case of navigation in the owner for a port as far as I can tell. But I consider that a bug in the spec -- navigation _should_ disentangle ports. Why? How would it work? If the port gets disentangled, it means the document has to set the salvegeable flag to false, so that navigating back doesn't put the document in a broken state. Do browsers do that? Is it the best thing to do? What if another document also has a reference to the port, does it still get disentangled when the owner gets navigated? -- Simon Pieters Opera Software
Re: [whatwg] Stroking algorithm in Canvas 2d
On Mon, Oct 14, 2013 at 1:54 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Oct 11, 2013 at 6:17 AM, Justin Novosad ju...@google.com wrote: So far, there are a few differences between the spec and the graphics API I work with (skia) that attracted my attention: 1) the line caps on individual dashes: this is not yet resolved, and it is pretty far on my to do list (low volume of complaints) Can you tell me what is wrong with line caps on dashes? Is that your proposal to not have dashes on join and endcaps? I just re-tested this, and it looks like the problem was partially fixed under my radar (a skia improvement probably?). There is still the issue that dashes of length 0 are not being rendered in Chrome. When using round lineCaps, for example, a dash of length 0 should be rendered as a dot. So that part still needs to be fixed. Some devs are currently working around the issue by using small values (e.g. 0.001) instead of 0. 2) the way of handling dash sequences with an odd number of elements (concatenate the sequence onto itself to make it even): this was easy to resolve, although I have reservations about this. I think it may feel unnatural to many graphics designers. Yes, that looked very odd to me too. Usually when you set an array, you get the same array values back. To bad that it already landed in 3 browsers... The Abilene paradox strikes again :-( 3) The method of mapping the dash pattern to the path: I suspected this might be a problem, but I didn't really pay much attention to it until this thread started. 4) Inflating paths: this did not worry me at all. I was confident that any differences in results would be negligible and decided not to even investigate unless someone reported a bug. True. It didn't really matter for now. However, if we allow getting the stroke outlines in the future, we needed a better description how stroking is done. The current wording of Sweeping a line describes how you create a stroke region and not an inflated path. +1 to that.
Re: [whatwg] HTTP Forms extension specification
On Mon, Oct 14, 2013 at 9:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Feb 2013, Cameron Jones wrote: http://cameronjones.github.com/form-http-extensions/index.html On Fri, 22 Feb 2013, Cameron Jones wrote: The motivations are the same which support declarative over imperative programming, access to the HTTP protocol methods and headers (ETags, versioning), greater flexibility over payload binding and the ability to avoid using cookies for session continuation. Can you elaborate? What are the end-user use cases that this proposal would enable, that are not possible today? The direct enabler for the end-user is the ability to interact with web sites under the guarantees of HTTP method semantics without the need for them to be using a Javascript-enabled browser. The HTTP idempotent methods (PUT, DELETE) guarantee that that multiple identical requests should have the same effect as a single request. This alleviates the end-user from potentially executing multiple requests either from hitting 'refresh' or the 'back button' when such requests would have unintended consequences. The ability to set request headers (also without JS) provides a universal method for employing session continuation and request verification through the application of 'capability-based security' tokens as HTTP headers. This can be applied for GET requests without polluting URL queries. The use of HTML declarations, as opposed to Javascript imperative statements, provides the structure of a website for static generation and analysis. Web crawlers, screen readers and other HTML tools will have the ability to read, validate or otherwise process the site which would otherwise be effectively impossible if required to define the structure in imperative form. The extension specification also includes the ability to declare HTTP authentication forms, and the ability to 'logout' and clear the authentication cache. In lieu of a Javascript interface, this provides the only ability of this functionality. Thanks, Cameron Jones
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10 Oct 2013, at 15:05, Simon Pieters sim...@opera.com wrote: I've added CSS.escape(foo). https://dvcs.w3.org/hg/csswg/rev/09466af95185 Very useful, thanks. Here’s a polyfill for `CSS.escape`: https://github.com/mathiasbynens/CSS.escape Tests: https://github.com/mathiasbynens/CSS.escape/blob/master/tests/tests.js
Re: [whatwg] Behavior of anchor element when wrapping floated images
On Mon, Oct 14, 2013 at 4:04 PM, Bruno Racineux br...@hexanet.net wrote: I've ran into the following layout issue while using the accessibility audit extension on Chrome. https://github.com/GoogleChrome/accessibility-developer-tools/issues/64 In brief, there is an accessibility issue with floated images within an anchor element, which is present on the web on a potentially large scale, making links to images invisible to keyboard readers. Should the anchor tag be made to wrap around a floated image to address this? Presumably, it'd think the container size should match that of the clickable area? (instead of being 0 0) Or should a recommendation be made to float the anchor instead as the only way to get around this? I would appreciate some feedback. This is a CSS issue, not an HTML one - floated elements don't affect the sizes of their container elements, so if you float out all the contents, it collapses to a 0-height element (and, for inlines, 0-width). The semantics are still fine. You can avoid any weirdness with focus outlines by floating the a instead - it should have the same effect. ~TJ
Re: [whatwg] Stroking algorithm in Canvas 2d
Ian, at this point, should I file a bug on the dashing algorithm, or is the email thread enough? On Thu, Oct 10, 2013 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 Oct 2013, Justin Novosad wrote: On Thu, Oct 10, 2013 at 5:48 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 Oct 2013, Rik Cabanier wrote: setLineDash([30]); rect(10, 10, 100, 100); rect(10, 110, 100, 100); rect(10, 210, 100, 100); stroke(); These rectangles should look the same. I presume you mean I want those rectangles to look the same. I don't see any a priori objective reason why they should look the same. And is there an a priori objective reason why they should look different? It seem pretty obvious to me that there would be way more designers wanting the rects to look the same than there would be wanting the rects to look different. [...] should we not provide the most desirable behavior by default? We should definitely provide the most desirable behaviour by default. The question is, what is it? The only argument one way or the other I've seen on this so far is the idea that if we don't reset, we get a more balanced distribution of the dash density, whereas if we do reset, the dash density is biased towards the start of the dash pattern. The actual most desireable behaviour may in fact be neither Rik's proposal nor mine, but something more like yours, where we somehow balance the dashes between each node in the path, but I don't really know exactly how to do that. Just so we're clear, I really don't have a strong opinion on this issue. I just want to make sure we apply the same rigour to deciding what the model should be as we do to everything else, and that means not just doing things because they've always been done that way, but instead either figuring out why they've always been done that way, or starting from first principles or data and deriving the right behaviour. So far, the proposals seem to be to reset on each subpath, to not reset on each subpath, and to add more features to the API. If we don't want to add more features (features are expensive), then we're left with reset and not reset. You can do everything you can do with resetting in the no-resetting case; you can't do everything you can do without resetting in the reset case. So the only strong argument there is that one of the two ways provides more power to authors. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stroking algorithm in Canvas 2d
On Tue, 15 Oct 2013, Rik Cabanier wrote: at this point, should I file a bug on the dashing algorithm, or is the email thread enough? Do you prefer to track things with a bug or e-mail? Either is fine by me, I just find it confusing when we have both. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stroking algorithm in Canvas 2d
On Tue, Oct 15, 2013 at 1:01 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 15 Oct 2013, Rik Cabanier wrote: at this point, should I file a bug on the dashing algorithm, or is the email thread enough? Do you prefer to track things with a bug or e-mail? Either is fine by me, I just find it confusing when we have both. Whatever is fasted :-) For me, email is best since it gets the most eyeballs.
Re: [whatwg] Canvas in workers
Robert, I think your argument makes sense. The DrawingBuffer mechanism described in http://wiki.whatwg.org/wiki/CanvasInWorkers can be made implicit and hidden under the hood in a way that is just as memory efficient by using the right combination of read locks and copy-on-write. However, I have concerns about how resizing would be handled by the proposed commit mechanism. I think there is no perfect solution, but whatever we do, I think animation smoothness should be a primary concern, so we should avoid blocking any threads and we should avoid dropping frames as much as possible. I like the concept of handling canvas size mismatches that is brought forward in the CanvasInWorkers proposal. If we put that idea into the WorkerCanvas proposal, here is an idea of how commits could handle resizes asynchronously: 1) Main thread executes some JS that changes the size of the canvas, and posts an event to the Worker in order to propagate the change to the WorkerCanvas. 2) On the worker thread, the WorkerCanvas stores the new size, but does not apply it right away to avoid resetting canvas contents mid frame. 3) commit() is called on the WorkerCanvas, causing the current canvas contents to be sent to the main thread for display, and the new canvas size comes into effect (lazily?) 4) The main thread receives the committed pixels. N.B.: The size of the received buffer does not match canvas element's intrinsic size 5) At paint time, the canvas contents get displayed respecting the canvas element's current size. The mismatched pixel buffer is either streched/squashed or clipped/padded to fit. An alternative that was proposed earlier in this (e-mail) thread was for the main thread to reject commits when there is a size mismatch. That does respect the desire to be asynchronous, and it avoid the inconvenience of resizing contents, but I don't like the idea because it means there can be cases where we may have a large number of consecutive dropped frames. Think of drag-resizing for example. We should avoid making that common use case behave poorly. On Mon, Oct 14, 2013 at 4:34 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell k...@google.com wrote: Would you mind looking at the proposal http://wiki.whatwg.org/wiki/CanvasInWorkers and commenting on it? Sure. Kyle and I looked at it while we were working on our proposal. The main issues I have with it are that rearchitecting canvas to introduce the DrawingBuffer layer of abstraction seems unnecessarily complex, and it doesn't handle direct presentation of frames from the worker, bypassing the main thread. There's been some recent discussion in the WebGL WG on this topic and concerns were raised from other parties at Mozilla about the DrawingBuffer proposal above, including that it isn't possible to render from a worker without synchronizing with the main thread. This is a huge limitation. For games and other animated content, achieving a stable frame rate is super important and a key motivation for adding canvas support to workers. My vision for handling the Maps use-cases based on our proposal is this: the worker renders to one or more WorkerCanvases, then does createImageBitmap(canvasContext), then ships the ImageBitmap(s) to the main thread using postMessage, and then renders those ImageBitmaps either by drawing them to a canvas or in some more direct way. This can all be implemented in a zero-copy way with the APIs currently in the spec, though it's not trivial. You'd need to do a few optimizations: -- createImageBitmap(canvasContext) would take a lazy snapshot of the canvas contents; i.e., further modifications to the canvas would trigger a copy (on the worker), but if the canvas is untouched no copy is required. -- structured clone of the ImageBitmap would not copy. This may actually require a small spec change. -- drawing an ImageBitmap to a 2D canvas, if it covers the whole canvas, would simply replace the canvas buffer with the ImageBitmap contents (and perform copy-on-write if the script later makes changes to that canvas). These optimizations would all be useful in other contexts too. Whatever happens with canvas-in-a-worker, I bet we'll end up doing these optimizations for other reasons. It might make sense to create an API that renders an ImageBitmap more directly than drawing it to a canvas. For example we could create an API that allows an img element to render an ImageBitmap. It would be a bit simpler for authors and perhaps a bit simpler to implement than the final optimization in my list above. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Canvas in workers
On Sun, Oct 13, 2013 at 7:55 PM, David Bruant bruan...@gmail.com wrote: Not directly related, but I imagine requestAnimationFrame doesn't work in a worker. How can a script know when to stop drawing on a given canvas? rAF doesn't work in a worker, but that is easy to work around. You can have a rAF handler on the main thread that propagates the signal to your workers by posting a rAF message to them.
Re: [whatwg] Canvas in workers
On Wed, Oct 16, 2013 at 10:06 AM, Justin Novosad ju...@google.com wrote: If we put that idea into the WorkerCanvas proposal, here is an idea of how commits could handle resizes asynchronously: 1) Main thread executes some JS that changes the size of the canvas, and posts an event to the Worker in order to propagate the change to the WorkerCanvas. 2) On the worker thread, the WorkerCanvas stores the new size, but does not apply it right away to avoid resetting canvas contents mid frame. 3) commit() is called on the WorkerCanvas, causing the current canvas contents to be sent to the main thread for display, and the new canvas size comes into effect (lazily?) 4) The main thread receives the committed pixels. N.B.: The size of the received buffer does not match canvas element's intrinsic size 5) At paint time, the canvas contents get displayed respecting the canvas element's current size. The mismatched pixel buffer is either streched/squashed or clipped/padded to fit. Step 5 has an issue that different apps might want to make different choices about whether and how to scale/pad/crop. But I think here we can leverage CSS3 object-fit and object-position properties: http://dev.w3.org/csswg/css-images-3/#object-fit Let's make those apply to canvas, where the replaced content is the canvas backing store! Then we would modify your proposal a little bit. Let's say that the main thread cannot modify the canvas buffer size after the canvas has been transferred. If you want to change the buffer size, you'll have to postMessage your worker and have it update the buffer size. When the worker commits a canvas buffer with a size that doesn't match the element size, object-fit and object-position are consulted to determine what gets rendered. Those values can be sent to the compositor, so we can always render the right thing. This means a worker constantly producing frames without yielding can't be notified of a buffer size change, but I don't think that's a big deal. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Canvas in workers
On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad ju...@google.com wrote: rAF doesn't work in a worker, but that is easy to work around. You can have a rAF handler on the main thread that propagates the signal to your workers by posting a rAF message to them. That isn't a good solution since it forces the app to drop frames if the main thread is blocked. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Canvas in workers
On Mon, Oct 14, 2013 at 1:34 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell k...@google.com wrote: Would you mind looking at the proposal http://wiki.whatwg.org/wiki/CanvasInWorkers and commenting on it? Sure. Kyle and I looked at it while we were working on our proposal. The main issues I have with it are that rearchitecting canvas to introduce the DrawingBuffer layer of abstraction seems unnecessarily complex, and it doesn't handle direct presentation of frames from the worker, bypassing the main thread. Note that the CanvasInWorkers draft solves some other longstanding issues not addressed by the WorkerCanvas proposal. It provides the ability to render to multiple canvases from a single context, whether workers are involved or not. It achieves ideal memory utilization by being very explicit in the API, without the need for extensive and subtle optimizations behind the scenes. It's worth considering whether a change to the CanvasInWorkers proposal could support presenting frames directly from the worker. There's been some recent discussion in the WebGL WG on this topic and concerns were raised from other parties at Mozilla about the DrawingBuffer proposal above, including that it isn't possible to render from a worker without synchronizing with the main thread. This is a huge limitation. For games and other animated content, achieving a stable frame rate is super important and a key motivation for adding canvas support to workers. My vision for handling the Maps use-cases based on our proposal is this: the worker renders to one or more WorkerCanvases, then does createImageBitmap(canvasContext), then ships the ImageBitmap(s) to the main thread using postMessage, and then renders those ImageBitmaps either by drawing them to a canvas or in some more direct way. This can all be implemented in a zero-copy way with the APIs currently in the spec, though it's not trivial. You'd need to do a few optimizations: -- createImageBitmap(canvasContext) would take a lazy snapshot of the canvas contents; i.e., further modifications to the canvas would trigger a copy (on the worker), but if the canvas is untouched no copy is required. -- structured clone of the ImageBitmap would not copy. This may actually require a small spec change. -- drawing an ImageBitmap to a 2D canvas, if it covers the whole canvas, would simply replace the canvas buffer with the ImageBitmap contents (and perform copy-on-write if the script later makes changes to that canvas). These optimizations would all be useful in other contexts too. Whatever happens with canvas-in-a-worker, I bet we'll end up doing these optimizations for other reasons. I agree that it's probably possible to make this work. It is still worth considering whether these optimizations are going to be fragile, and whether developers will fall off a performance cliff if something subtle changes in their code or in the browser's behavior in the future. It might make sense to create an API that renders an ImageBitmap more directly than drawing it to a canvas. For example we could create an API that allows an img element to render an ImageBitmap. It would be a bit simpler for authors and perhaps a bit simpler to implement than the final optimization in my list above. That's an interesting possibility. It would probably be quite a bit simpler to both specify and implement rather than using a canvas on the receiving end. -Ken Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Canvas in workers
Le 16/10/2013 00:12, Robert O'Callahan a écrit : On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad ju...@google.com mailto:ju...@google.com wrote: rAF doesn't work in a worker, but that is easy to work around. You can have a rAF handler on the main thread that propagates the signal to your workers by posting a rAF message to them. That isn't a good solution since it forces the app to drop frames if the main thread is blocked. If the main thread is blocked, the app drops frames anyway, no? Anyway, on not-so-good hardware (most mobiles?), workers communication cost is non-trivial and eats a bit of the 16,6ms budget. A friend told me recently that in AS3, objects on the screen can all listen to a beforeframe event (or something like that). In web platform equivalents, they have a per-element requestAnimationFrame (instead of only a global one). I found this idea interesting. Among other things, it allows implementors to not emit the event if the object isn't on the screen. It feels like it encourages good practices too; if my canvas element is too low in the document to be on screen, maybe I don't want to draw on it... I wonder how many people check if the thing they want to update is actually on screen... In the case of canvas, the UA not only could decide to not dispatch events, but could also tell precisely which part of the canvas is visible so that if the app cares or is capable or partial canvas paints, it can decide to do so. In case the main thread is blocked, events can be saved in the worker and save processing resource/battery. David
Re: [whatwg] Stroking algorithm in Canvas 2d
On Mon, 9 Sep 2013, Stephan Yhann wrote: On Thu, 5 Sep 2013, Rik Cabanier wrote: we've looked over the algorithm in the Canvas spec that describes how strokes are computed. [1] We think that this section is making some incorrect assumptions. For instance, the dashes are calculated over the total lenght of all subpaths, but each subpath should be treated separately. That's intentional, otherwise if you stroke an already-dashed line, you get weird results. Can you clarify what you mean by an already-dashed line. Do you mean a line that has been split in to shorter segments, each of dash length? If so, can you describe the weird results? I mean that if you have a line that consists of a series of dashes, and you want to stroke it with a dash pattern, you'll get ugly results if you start again with each subpath. For example: // http://goo.gl/rPN5Eg c.setLineDash([3]) c.beginPath(); c.moveTo(100,100); c.lineTo(120,100); c.moveTo(130,100); c.lineTo(150,100); c.moveTo(160,100); c.lineTo(180,100); c.moveTo(190,100); c.lineTo(210,100); c.stroke(); You get something like: -- -- -- - -- -- -- - -- -- -- - -- -- -- - ...instead of: -- -- -- - - -- -- ---- -- ---- -- -- - ...which would look more balanced. Also, I did not see a reference to curves and how they should be handled. Could you elaborate on what text in the spec you think doesn't handle curved lines? On Thu, 10 Oct 2013, Rik Cabanier wrote: On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad ju...@google.com wrote: http://jsfiddle.net/ZxR6P/1/ Yes, that looks like Align dashes to corners and path ends I've filed a bug for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528 This thread now is mainly about what the default should be. On Thu, 10 Oct 2013, Justin Novosad wrote: On Thu, Oct 10, 2013 at 4:20 PM, Rik Cabanier caban...@gmail.com wrote: would you change Canvas' stroking behavior so it no longer matches SVG [...] and your underlying graphics libraries? My first reflex is to say that of course it would be convenient for implementors and web developpers alike if dashes were consistent across all web standards. I don't feel super strongly about that though, and could easily be convinced otherwise. How much does that really matter to the Web? On Thu, 10 Oct 2013, Stephan Yhann wrote: I am curious as to the motivation for creating a new dashing model instead of adopting an existing model that developers and designers are all familiar with. Is the new model addressing specific problems that the well know dashing model cannot solve. Yes; it's addressing the problems that have been discussed in this thread several times. - the dash density is biased to the start of the pattern if you reset with each subpath, which is aesthetically displeasing - if the pattern resets at each subpath, then you can't take a dashed path and then split it arbitrarily, moving subparts of the path, without the pattern suddenly shifting when the path is cut. If we are going to have per-point control over this behaviour (as suggested in the aforementioned bug), then I don't mind so much what the default behaviour is. Introducing a new dashing model adds complexity to conversions from one graphics model to another, e.g., when printing a web page or saving it as PDF, converting from PDF to HTML or exporting to HTML from current WYSIWYG drawing/design programs. For example, PDF and SVG both have an operator to stroke and fill a path. Compound paths, (e.g. a donut with an inner and outer circle), that are both stroked and fill would need to be duplicated and broken up into two paths to be drawn correctly into this model - assuming they are created in an application/format that works with the PDF/SVG stroking model. Additionally, I think that having dashes continue across sub paths introduces uncertainty in the graphic design. Consider a designer editing a sub-path on a dashed path with multiple sub paths. Changing the length of one sub-path will affect the dashing on the other sub paths. This is really counter intuitive to what is expected. Also, I think that from a designers perspective it will be harder to create a desired look on compound paths (unless you like adding numbers as you work). I think the placement of the dash on start and end points of paths and sub paths is the critical design element and continuing dashing across sub paths defeats this. These are good arguments for the reset behaviour. I don't see them as particularly more or less compelling than the arguments above. If we are going to eventually allow both behaviours, it's kind of moot; all that matters then is the default. Finally, I think the join and other effects suggested as motivations for the new dashing model are higher level and should be styles settings or similar where the underlying
Re: [whatwg] Canvas in workers
On Mon, Oct 14, 2013 at 1:20 PM, Kenneth Russell k...@google.com wrote: 1) Rendering from a worker and displaying on the main thread with no extra blits of the rendering results 2) Allows one context to render to multiple canvases 3) Supports resizing of the drawing buffer The WorkerCanvas proposal should allow #1 and #3. (It doesn't support #3 for purely offscreen worker canvases, but that'd be easy to add.) #2 would be nice with WebGL, where setting up extra contexts can be expensive, and it may be simpler to do at the Canvas level than by mimicing OpenGL (eg. shared resources across contexts). There's been some recent discussion in the WebGL WG on this topic and concerns were raised from other parties at Mozilla about the DrawingBuffer proposal above, including that it isn't possible to render from a worker without synchronizing with the main thread. Your proposal does seem to require synchronization with the main thread, at least with double-buffering. You postMessage the DrawingBuffer to the main thread to ask it to be displayed. The worker can't start drawing the next frame until it knows that the drawing buffers have been flipped; the buffer flip happens in the main thread, when transferDrawingBufferToCanvas is called. WorkerCanvas performs the flip itself in the worker, when .commit() is called (and possibly also when the script returns). Even if the main thread is busy, the worker should be able to do this immediately. It does need to be a thread-safe operation, but it doesn't need to block if the UI thread is busy. This proposal doesn't handle synchronizing DOM updates with threaded canvas updates, but it seems like that inherently requires synchronization... -- Glenn Maynard
Re: [whatwg] Canvas in workers
On Wed, Oct 16, 2013 at 11:55 AM, David Bruant bruan...@gmail.com wrote: If the main thread is blocked, the app drops frames anyway, no? Not necessarily. We can allow workers to present frames to the compositor without synchronizing with the main thread. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Canvas in workers
On Wed, Oct 16, 2013 at 11:55 AM, Kenneth Russell k...@google.com wrote: On Mon, Oct 14, 2013 at 1:34 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell k...@google.com wrote: Would you mind looking at the proposal http://wiki.whatwg.org/wiki/CanvasInWorkers and commenting on it? Sure. Kyle and I looked at it while we were working on our proposal. The main issues I have with it are that rearchitecting canvas to introduce the DrawingBuffer layer of abstraction seems unnecessarily complex, and it doesn't handle direct presentation of frames from the worker, bypassing the main thread. Note that the CanvasInWorkers draft solves some other longstanding issues not addressed by the WorkerCanvas proposal. It provides the ability to render to multiple canvases from a single context, whether workers are involved or not. That may be a useful feature, but I'd like to see it justified in its own right. It achieves ideal memory utilization by being very explicit in the API, without the need for extensive and subtle optimizations behind the scenes. We can be more explicit with ImageBitmaps. We could provide WorkerCanvas.transferToImageBitmap which transfers the current canvas contents to an ImageBitmap and clears the canvas. (Canvas implementations are already optimized to support a zero-cost cleared state, because existing benchmarks require it.) Sharing ImageBitmap contents across threads during structured clone is not subtle. We can add an HTMLImageElement.srcObject attribute which could take a Blob or an ImageBitmap to enable explicit zero-copy rendering of ImageBitmaps. Would that be explicit enough for you? Personally I think high-performance manipulation of ImageBitmaps would be more generally useful than detachable DrawingBuffers, and would be easier for authors to understand. If you squint, WorkerCanvas.transferToImageBitmap is similar to detaching a DrawingBuffer. But I don't see a need to reattach a buffer to a canvas for further drawing. Do you? It's worth considering whether a change to the CanvasInWorkers proposal could support presenting frames directly from the worker. Sure, by adding a commit() method to DrawingBuffer. Right? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Canvas in workers
On Tue, Oct 15, 2013 at 4:41 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Oct 16, 2013 at 11:55 AM, Kenneth Russell k...@google.com wrote: On Mon, Oct 14, 2013 at 1:34 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell k...@google.com wrote: Would you mind looking at the proposal http://wiki.whatwg.org/wiki/CanvasInWorkers and commenting on it? Sure. Kyle and I looked at it while we were working on our proposal. The main issues I have with it are that rearchitecting canvas to introduce the DrawingBuffer layer of abstraction seems unnecessarily complex, and it doesn't handle direct presentation of frames from the worker, bypassing the main thread. Note that the CanvasInWorkers draft solves some other longstanding issues not addressed by the WorkerCanvas proposal. It provides the ability to render to multiple canvases from a single context, whether workers are involved or not. That may be a useful feature, but I'd like to see it justified in its own right. There has been a lot of developer feedback on the WebGL mailing lists over the past couple of years about exactly this feature. Web sites like Turbosquid want to present lots of little thumbnails of models -- see for example http://www.turbosquid.com/Search/3D-Models/Vehicle/Car -- and have them be interactive. It's too resource-intensive to create a separate WebGL context for each. The most direct solution is to allow one context to render to multiple canvases. It achieves ideal memory utilization by being very explicit in the API, without the need for extensive and subtle optimizations behind the scenes. We can be more explicit with ImageBitmaps. We could provide WorkerCanvas.transferToImageBitmap which transfers the current canvas contents to an ImageBitmap and clears the canvas. (Canvas implementations are already optimized to support a zero-cost cleared state, because existing benchmarks require it.) Sharing ImageBitmap contents across threads during structured clone is not subtle. We can add an HTMLImageElement.srcObject attribute which could take a Blob or an ImageBitmap to enable explicit zero-copy rendering of ImageBitmaps. Would that be explicit enough for you? Yes, that generally sounds good. Personally I think high-performance manipulation of ImageBitmaps would be more generally useful than detachable DrawingBuffers, and would be easier for authors to understand. If you squint, WorkerCanvas.transferToImageBitmap is similar to detaching a DrawingBuffer. But I don't see a need to reattach a buffer to a canvas for further drawing. Do you? Not immediately. The ability to transfer out the canvas's contents, and render them in an HTMLImageElement without incurring an extra blit, should address the Maps team's requirements. Actually, adding transferToImageBitmap to HTMLCanvasElement as well would address the use case of rendering to multiple targets using one context. Instead of using multiple canvases as the targets, one would simply use multiple images. That sounds appealing. If WorkerCanvas is changed so that its width and height are mutable within the worker as you mentioned above, it sounds like it's addressing the known use cases. It's worth considering whether a change to the CanvasInWorkers proposal could support presenting frames directly from the worker. Sure, by adding a commit() method to DrawingBuffer. Right? I'm not exactly sure how it would be done. In the proposal as written, the DrawingBuffer's not shared between threads, only transferred. -Ken Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
[whatwg] Avoiding synchronous iframe load
Hi,
I'm trying to make page loads on iframe always asynchronous in WebKit.
However, the current specification appears to indicate that the navigation
happens synchronously.
Namely, in the following example, the first alert should be true as far as I
read the specification.
script var a = false; /script
iframe src=javascript:a=true onload=a = true/iframe
script alert(a); /* or even setTimeout(function(){alert(a);},0); */
setTimeout(function(){alert(a);},10) /script
On the other hand, Firefox and Internet Explorer do not synchronously load
iframes, and the first alert in the example above yields false although it
yields true on WebKit and Blink.
Am I reading the specification wrong/missing something? If not, could you
amend the specification to make page loads on an iframe always asynchronous?
- R. Niwa
Re: [whatwg] Stroking algorithm in Canvas 2d
On Tue, Oct 15, 2013 at 4:18 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Sep 2013, Stephan Yhann wrote: On Thu, 5 Sep 2013, Rik Cabanier wrote: we've looked over the algorithm in the Canvas spec that describes how strokes are computed. [1] We think that this section is making some incorrect assumptions. For instance, the dashes are calculated over the total lenght of all subpaths, but each subpath should be treated separately. That's intentional, otherwise if you stroke an already-dashed line, you get weird results. Can you clarify what you mean by an already-dashed line. Do you mean a line that has been split in to shorter segments, each of dash length? If so, can you describe the weird results? I mean that if you have a line that consists of a series of dashes, and you want to stroke it with a dash pattern, you'll get ugly results if you start again with each subpath. For example: // http://goo.gl/rPN5Eg c.setLineDash([3]) c.beginPath(); c.moveTo(100,100); c.lineTo(120,100); c.moveTo(130,100); c.lineTo(150,100); c.moveTo(160,100); c.lineTo(180,100); c.moveTo(190,100); c.lineTo(210,100); c.stroke(); You get something like: -- -- -- - -- -- -- - -- -- -- - -- -- -- - ...instead of: -- -- -- - - -- -- ---- -- ---- -- -- - ...which would look more balanced. That's debatable :-) To me, the first one looks more balanced. Also, I did not see a reference to curves and how they should be handled. Could you elaborate on what text in the spec you think doesn't handle curved lines? I think that was addressed with your changes that describe that a stroke is like sweeping a line. On Thu, 10 Oct 2013, Rik Cabanier wrote: On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad ju...@google.com wrote: http://jsfiddle.net/ZxR6P/1/ Yes, that looks like Align dashes to corners and path ends I've filed a bug for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528 This thread now is mainly about what the default should be. On Thu, 10 Oct 2013, Justin Novosad wrote: On Thu, Oct 10, 2013 at 4:20 PM, Rik Cabanier caban...@gmail.com wrote: would you change Canvas' stroking behavior so it no longer matches SVG [...] and your underlying graphics libraries? My first reflex is to say that of course it would be convenient for implementors and web developpers alike if dashes were consistent across all web standards. I don't feel super strongly about that though, and could easily be convinced otherwise. How much does that really matter to the Web? On Thu, 10 Oct 2013, Stephan Yhann wrote: I am curious as to the motivation for creating a new dashing model instead of adopting an existing model that developers and designers are all familiar with. Is the new model addressing specific problems that the well know dashing model cannot solve. Yes; it's addressing the problems that have been discussed in this thread several times. - the dash density is biased to the start of the pattern if you reset with each subpath, which is aesthetically displeasing - if the pattern resets at each subpath, then you can't take a dashed path and then split it arbitrarily, moving subparts of the path, without the pattern suddenly shifting when the path is cut. If we are going to have per-point control over this behaviour (as suggested in the aforementioned bug), then I don't mind so much what the default behaviour is. Introducing a new dashing model adds complexity to conversions from one graphics model to another, e.g., when printing a web page or saving it as PDF, converting from PDF to HTML or exporting to HTML from current WYSIWYG drawing/design programs. For example, PDF and SVG both have an operator to stroke and fill a path. Compound paths, (e.g. a donut with an inner and outer circle), that are both stroked and fill would need to be duplicated and broken up into two paths to be drawn correctly into this model - assuming they are created in an application/format that works with the PDF/SVG stroking model. Additionally, I think that having dashes continue across sub paths introduces uncertainty in the graphic design. Consider a designer editing a sub-path on a dashed path with multiple sub paths. Changing the length of one sub-path will affect the dashing on the other sub paths. This is really counter intuitive to what is expected. Also, I think that from a designers perspective it will be harder to create a desired look on compound paths (unless you like adding numbers as you work). I think the placement of the dash on start and end points of paths and sub paths is the critical design element and continuing dashing across sub paths defeats this. These are good arguments for the reset behaviour. I don't see them as particularly more or less compelling than the arguments above. If we are
