Re: [whatwg] Reviving ImageBitmap options: Intend to spec and implement

On Thu, Feb 11, 2016 at 9:27 AM, Justin Novosad wrote: > On Wed, Feb 10, 2016 at 2:38 PM, Ashley Gullen wrote: > > > ImageBitmap is not useful for getting the data from: it still requires > > synchronous use of a canvas to turn in to an ImageData. I would

Re: [whatwg] VIDEO and pitchAdjustment

On Wed, Sep 2, 2015 at 5:30 AM, David Singer <sin...@apple.com> wrote: > On Sep 1, 2015, at 4:03 , Robert O'Callahan <rob...@ocallahan.org> wrote: > > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25 > fps, > > keyframe every 10s. Storing all t

Re: [whatwg] VIDEO and pitchAdjustment

On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: > QuickTime supports full variable speed playback and has done for well over > a decade. With bidirectionally predicted frames you need a fair few buffers > anyway, so generalising to full variable wait is easier than

Re: [whatwg] VIDEO and pitchAdjustment

On Sat, Aug 29, 2015 at 8:18 AM, James Ross ja...@james-ross.co.uk wrote: Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my

Re: [whatwg] VIDEO and pitchAdjustment

On Fri, Aug 28, 2015 at 6:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: It would be useful to have pitch adjustment for VIDEO element. There is playbackRate, to control playback speed — useful!* And there is vv.mozPreservesPitch, in Firefox, which can be set to false, so that pitch will

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 11:02 PM, Ashley Gullen ash...@scirra.com wrote: We have tried to implement half-vsync rate ourselves in the past by simply ignoring alternate rAFs, but in practice it looked terrible - I guess we broke implementation-defined heuristics that expect every rAF call to do

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick voll...@chromium.org wrote: On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad ju...@google.com wrote: On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers rby...@chromium.org wrote: Sounds great to me. I agree this is an important scenario. *Ian*,

[whatwg] Worker requestAnimationFrame

For OffscreenCanvas we need a way for a Worker to draw once per composited frame. I suggest we create DedicatedWorkerGlobalScope.requestAnimationFrame(callback) that works similarly to Window.requestAnimationFrame. To reduce latency for applications such as VR, I'd like to run the callback after

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Thu, Jul 16, 2015 at 8:44 PM, Philip Jägenstedt phil...@opera.com wrote: OK, so perhaps file two bugs for each of those things and continue discussion there? I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28956. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com wrote: I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players that can be created, or limits on how much stuff (decoders) they set up

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com wrote: Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Probably. Is there a reason it doesn't do this in mobile Firefox? We don't want a page with

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com wrote: If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload=auto,

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise not to assume anything state? The auto state is already suitable named and defined for that, so if implementing auto as anything other than try to reach

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

Apart from the problems already discussed here, there is currently no specced or interoperably implemented way to set a preload value that guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be reached ... auto may do one of those things, but it doesn't have to, and in fact on

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt phil...@opera.com wrote: Unsurprisingly, I like this, as it's basically what Presto did. However, I think preload=metadata should reach HAVE_CURRENT_DATA, because you do want to decode the first frame. The naming mismatch is weird, but oh well.

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt phil...@opera.com wrote: On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan rob...@ocallahan.org wrote: In Gecko, video preload=metadata doesn't fire canplay. This is allowed (encouraged, even) by the spec, since we can efficiently satisfy

Re: [whatwg] preload=metadata elements don't necessarily fire canplay

On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt phil...@opera.com wrote: On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt phil...@opera.com wrote: On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan rob

Re: [whatwg] Apple's new link rel=icon mask not-quite-favicon syntax causing problems in other browsers; needs standardization?

On Mon, Jun 15, 2015 at 12:40 PM, Daniel Holbert dholb...@mozilla.com wrote: There was a suggestion on one of the bugs that we simply ignore link tags that have a mask attribute; this may be what we want to do to avoid having a zillion site-compat conversations, but I wanted to get other

[whatwg] preload=metadata elements don't necessarily fire canplay

In Gecko, video preload=metadata doesn't fire canplay. This is allowed (encouraged, even) by the spec, since we can efficiently satisfy preload=metadata by stopping decoding after one frame, and if we only decode one frame then readyState will not advance beyond HAVE_CURRENT_DATA. However, this

Re: [whatwg] High-density canvases

On Thu, Apr 16, 2015 at 7:07 AM, Justin Novosad ju...@google.com wrote: In the interest of moving forward with this, I began an experimental implementation of the renderedPixelWidth/Height propsal ( https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran into some issues,

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Wed, Apr 15, 2015 at 1:15 PM, Kenneth Russell k...@google.com wrote: If repeatedly transferring ImageBitmaps of the same size into the same img won't cause repeated re-layouts, that alleviates my concern about efficiency of using images as the output path. I expect that a single

Re: [whatwg] Canvas image to blob/dataurl within Worker

I guess there are really two different sets of use-cases: 1) Use-cases where the ImageBitmap is sized to fill a particular area of the screen. 2) Use-cases where the ImageBitmap is sized subject to some other constraints, e.g. you're processing an existing image. For #2, you want the

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Tue, Apr 14, 2015 at 9:03 AM, Justin Novosad ju...@google.com wrote: On Sun, Apr 12, 2015 at 5:41 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote: 3. Are onload and onerror events fired? This question applies

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote: Suppose src=myimage.png is set on an image element and then, while it is downloading, an ImageBitmap is transferred into it. This should behave as if src was removed just before the ImageBitmap is transferred into it. In

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Mon, Apr 13, 2015 at 9:41 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote: 5. Can the developer go back to having the img element contain what was set on 'src' and not what was transferred in? As written, yes

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sat, Apr 11, 2015 at 2:18 AM, Justin Novosad ju...@google.com wrote: Riddle me this: What would be the value an HTMLImageElement's src attribute after an ImageBitmap is transferred in? A data URL? What if the ImageBitmap was sourced from an actual resource with a URL, would we pipe that

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Thu, Apr 9, 2015 at 9:44 AM, Kenneth Russell k...@google.com wrote: On Tue, Apr 7, 2015 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org wrote: As far as I can tell, the only significant difference between this and WorkerCanvas is using an HTMLCanvasElement bitmaprenderer as a zero

Re: [whatwg] Recorder audio and save to server

On Tue, Apr 7, 2015 at 11:40 PM, Ashley Gullen ash...@scirra.com wrote: I've brought this up on other lists, but I think it's worth bringing up again here: it's a significant limitation in MediaRecorder that it can only work in real-time. If a user has a pre-recorded WAV file which is one hour

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Wed, Apr 8, 2015 at 11:41 AM, Kenneth Russell k...@google.com wrote: I apologize for taking so long to update this proposal, but it's now in a reasonable state: https://wiki.whatwg.org/wiki/OffscreenCanvas (Renamed per feedback from Anne -- thanks.) Please offer your feedback. Multiple

Re: [whatwg] Recorder audio and save to server

On Sat, Apr 4, 2015 at 9:28 PM, Narendra Sisodiya naren...@narendrasisodiya.com wrote: Hi, I am trying to do simple audio recording service. with help of navigator.getUserMedia, I am able to record audio in wav format. MediaRecorder is designed for exactly this.

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Thu, Mar 26, 2015 at 9:43 AM, Justin Novosad ju...@google.com wrote: createImageBitmap(myImageSource).then(function (image) { image.toBlob().then(admireYourShinyNewBlob); }); Oh, right. Sorry! Of course :-). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan rob...@ocallahan.org wrote: My understanding is that the current consensus proposal for canvas in Workers is not what's in the spec, but this: https

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Thu, Mar 26, 2015 at 8:40 AM, Justin Novosad ju...@google.com wrote: One idea we've been brewing that has not surfaced on this thread so far is that of having an ImageBitmap.toBlob(), which would return a Promise. Also, ImageBitmap should be transferable. This idea is just partially baked

Re: [whatwg] Canvas image to blob/dataurl within Worker

I'm getting confused as to what the problem is. To restate the advantages of async toBlob: suppose I have code that does drawStuffTo(context); context.canvas.toBlob().then(callback); // no further drawing to the canvas This has a few advantages over using getImageData and then encoding to

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier caban...@gmail.com wrote: On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier caban...@gmail.com wrote: Justin is worried that in order to make this asynchronous

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote: Ah, OK. I thought we were changing it for both cases. This will cause a lot of confusion... If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sat, Mar 21, 2015 at 3:38 PM, Rik Cabanier caban...@gmail.com wrote: Do you know how many site use toBlob in Firefox? A quick search on github shows a very high number of pages [1] so it might be too late to change. Maybe you can keep the callback and return a promise? None of them use

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Sat, Mar 21, 2015 at 1:13 AM, Jake Archibald jaffathec...@gmail.com wrote: Receiving a push message results in a 'push' event within the ServiceWorker. The likely action at this point is to show a notification. It should be possible to generate an image to use as an icon for this

Re: [whatwg] HTML video and IE, Safari, Firefox, Chrome

On Wed, Nov 5, 2014 at 3:46 AM, Martin Hoernig hoer...@in.tum.de wrote: Thank you Rob! I'm not sure what this means: Firefox fires the canplaythrough event after buffering is completed or halted instead of a bandwidth depending solution Do you mean that even when the data is arriving

Re: [whatwg] HTML video and IE, Safari, Firefox, Chrome

Thanks for the testing! Please file bugs against browsers where you feel they're not following the spec. I'm not sure what this means: Firefox fires the canplaythrough event after buffering is completed or halted instead of a bandwidth depending solution Do you mean that even when the data is

Re: [whatwg] HTML video and IE, Safari, Firefox, Chrome

On Tue, Nov 4, 2014 at 10:54 AM, Robert O'Callahan rob...@ocallahan.org wrote: I'm not sure what this means: Firefox fires the canplaythrough event after buffering is completed or halted instead of a bandwidth depending solution Do you mean that even when the data is arriving at a very high

Re: [whatwg] New feature: better integration with browser find interface

On Thu, Oct 30, 2014 at 9:15 AM, Peter Kasting pkast...@google.com wrote: If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the

Re: [whatwg] Gapless playback problems with web audio standards

On Sun, Oct 26, 2014 at 2:30 AM, David Kendal m...@dpk.io wrote: Hi, http://w3.org/mid/10b10a1d-8b84-4015-8d49-a45b87e4b...@dpk.io Web Audio should be usable for this. If it doesn't work due to brower bugs, we should fix the browser bugs. I know we've fixed bugs related to this in Firefox

Re: [whatwg] Gapless playback problems with web audio standards

On Tue, Oct 28, 2014 at 1:13 AM, David Kendal m...@dpk.io wrote: On 27 Oct 2014, at 12:08, Robert O'Callahan rob...@ocallahan.org wrote: Web Audio should be usable for this. If it doesn't work due to brower bugs, we should fix the browser bugs. I know we've fixed bugs related

Re: [whatwg] Support filters in Canvas

On Tue, Sep 30, 2014 at 12:45 AM, Rik Cabanier caban...@gmail.com wrote: Are you proposing that this is developed as a separate spec and not as an addition to the canvas specification? No, not really. I want to make sure that we have a pathway to standardize SVG filter support in canvas. If

Re: [whatwg] Support filters in Canvas

On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote: Can we limit it to just the set of CSS filter shorthands for now? I think other UA's are further behind in their implementation of integrating SVG filters in their rendering pipeline. How about we put CSS + SVG filters

Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage

It looks reasonable to me. How do these calls interact with globalAlpha etc? You talk about decomposing them to individual drawImage calls; does that mean each image draw is treated as a separate composite operation? Currently you have to choose between using a single image or passing an array

Re: [whatwg] Canvas-Only Document Type

If you want jank-free canvas rendering, you probably really want WebGL drawing from a Worker. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o

Re: [whatwg] High-density canvases

On Thu, Jul 3, 2014 at 3:03 AM, Justin Novosad ju...@google.com wrote: On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org wrote: This behavior seems sound at first glance, but because that arithmetic may induce a change to the intrinsic aspect ratio due to rounding

Re: [whatwg] High-density canvases

On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad ju...@google.com wrote: Example of a problematic renderedsizechange event listener: canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale); canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale); I don't know why

Re: [whatwg] High-density canvases

On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad ju...@google.com wrote: Hadn't thought of that. object-fit seems smells dangerous. I think we may need to define explicit behaviors for renderedPixelWidth/Height for the different object fit modes. I don't think so. Given

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad ju...@google.com wrote: I was wondering if there is anything we can do with this feature to prevent web apps from creating layout feedback loops. What I mean is that if the event listener for renderedsizechange changes the layout of the page in

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad ju...@google.com wrote: I was wondering if there is anything we can do with this feature to prevent web apps from creating layout feedback loops. What I mean

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan rob...@ocallahan.org wrote: To clarify, I think a version of option #1 would be the best way to go. renderedPixelWidth would return the current canvas buffer width when the canvas element's CSS specified value for 'width' is 'auto

Re: [whatwg] High-density canvases

On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier caban...@gmail.com wrote: Add a new event renderedsizechange to HTMLCanvasElement. This event does not bubble and is not cancelable. Whenever the value that would be returned by renderedPixelWidth orrenderedPixelHeight changes, queue a task to fire

Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell k...@google.com wrote: If there's no concern about potential duplicated functionality then let's add the attributes to the canvas element. They'll be easier for developers to understand and easier to verify as obviously correct. How should we

Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org wrote: I'll do that now. Done. http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o

Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from

Re: [whatwg] High-density canvases

On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad ju...@google.com wrote: +1 from me too. But I have one concern in terms of future proofing, because I would like to keep the door open for auto-resizing as a possible future improvement. In an eventual auto-resize proposal, we will want to make

Re: [whatwg] High-density canvases

On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell k...@google.com wrote: It is a little unfortunate that a canvas-specific solution is needed. Is it known whether document.getBoxQuads solves this problem in Firefox? It doesn't. Gecko (and I assume other engines) typically snaps CSS box edges

[whatwg] SVG cloning elements from HTML5

I just discovered https://svgwg.org/svg2-draft/embedded.html This looks very problematic. It ties SVG and HTML5 together in uncomfortable ways. For example, SVGIframeElement as specced has two width attributes. It's unclear how to keep this making sense as SVG and HTML5 evolve, e.g. as new

Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad ju...@google.com wrote: I am currently trying an experimental approach where canvases that are drawn to, but never read from (no toDataURL or getImageData calls) have their contents stored as a command buffer, rather than a pixel buffer. There

Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad ju...@google.com wrote: I am currently trying an experimental approach where canvases that are drawn to, but never read from (no toDataURL or getImageData calls

Re: [whatwg] High-density canvases

[Resurrecting old thread] On Tue, Sep 10, 2013 at 12:00 PM, Ian Hickson i...@hixie.ch wrote: It would be nice to fix these all at once, and I think we can, by introducing a configuration option on getContext(), in the style of WebGL: getContext('2d', { density: 'autosize' }); This would

Re: [whatwg] Proposal: toDataURL “image/png” compression control

On Sat, May 31, 2014 at 3:44 AM, Justin Novosad ju...@google.com wrote: My point is, we need a proper litmus test for the just do it in script argument because, let's be honnest, a lot of new features being added to the Web platform could be scripted efficiently, and that does not necessarily

Re: [whatwg] ImageBitmap feature requests

On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Maybe we should have img.srcObject similar to what we're doing for media elements. img.src can simply return about:imagebitmap or some such. That way you can also assign a Blob to an img element without having to do

Re: [whatwg] addPath and CanvasPathMethods

On Fri, Mar 21, 2014 at 8:15 AM, Justin Novosad ju...@google.com wrote: Sorry for the confusion, the point I was trying to make was unrelated to the CTM question (almost). My point is that the tesselation of a path is something that can be cached in a Path2D object. If you do this, you can

Re: [whatwg] Hit regions and events

On Wed, Mar 5, 2014 at 5:11 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan rob...@ocallahan.org wrote: The question remains: what should happen in Rik's example? More generally, is this event rerouting supposed to be able to trigger browser

Re: [whatwg] Hit regions and events

On Wed, Mar 5, 2014 at 12:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Feb 2014, Rik Cabanier wrote: For instance, if the fallback is an edit control and the user drag-selects some text on the canvas, is it expected that this text is also selected in the edit control? You can't

Re: [whatwg] Proposal: requestBackgroundProcessing()

On Fri, Feb 21, 2014 at 11:32 AM, Ashley Gullen ash...@scirra.com wrote: One solution is to make web workers able to access many of the same APIs the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then it might be practical to move a full game engine in to a worker. If that

[whatwg] HTML fieldset rendering

The rendering of fieldsets is under-specified at the moment, even taking into account http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-fieldset-and-legend-elements . 1) No spec describes how browsers move the top border of the fieldset down by about half the height

Re: [whatwg] Proposal: downsample while decoding image blobs in createImageBitmap()

Yes. Especially on these devices, JPEG decoding is undue latency. Also, Rik's suggestion makes an ImageBitmap just a thin wrapper around a Blob, with decoding performed every time we do a drawImage call. That's bad for performance in many cases. David's proposal lets the author be a little bit

Re: [whatwg] Questions regarding Path object

On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: Path is also too generic even in the context of graphics. If we later on want to add a path object for 3-dimensional paths, you end up with Path and Path3D? Yay for consistency. Path2D would immediately

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

If you return a path in user-space, what do you get if you call getCurrentPath with a singular transform? ctx.moveTo(0,0); ctx.lineTo(1,1); ctx.scale(0,0); var p = ctx.getCurrentPath(); ? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

On Sat, Nov 2, 2013 at 1:01 PM, Rik Cabanier caban...@gmail.com wrote: The latest Safari is shipping currentPath and Blink has implemented it behind a runtime flag. Could we put this in the specification? the proposal is for a new attribute on the 2d canvas rendering context: attribute

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

On Sun, Nov 3, 2013 at 3:03 PM, Rik Cabanier caban...@gmail.com wrote: On Sat, Nov 2, 2013 at 1:01 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Does this mean that ctx.currentPath != ctx.currentPath? Yes That's bad! Why would it be bad (apart from being different)? It means

Re: [whatwg] Canvas in workers

We talked through this proposal with a lot of Mozilla people in a meeting and collectively decided that we don't care about the case of workers that commit multiple frames to a canvas without yielding --- at least for now. So we want to remove commit() and copy the main-thread semantics that a

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

On Tue, Oct 22, 2013 at 12:39 AM, Glenn Maynard gl...@zewt.org wrote: Using ImageBitmap for this has a lot of issues. It requires synchronizing with scripts in the UI thread. It requires manualling resize your canvas repeatedly to fit different destinations. It also may potentially create

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

On Tue, Oct 22, 2013 at 4:37 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan rob...@ocallahan.org wrote: This code actually does something potentially useful which can't easily be done with attachToCanvas: generating a series of images as fast

Re: [whatwg] Canvas in workers

On Tue, Oct 22, 2013 at 7:31 PM, Kenneth Russell k...@google.com wrote: Robert, please don't remove those APIs from your proposal. They're needed in order to address known use cases, and splitting them off will make it difficult to understand how they interact with WorkerCanvas later. Yes,

Re: [whatwg] Canvas in workers

I got an account and I'm uploading the proposal now. 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

Re: [whatwg] Canvas in workers

On Tue, Oct 22, 2013 at 10:44 PM, Robert O'Callahan rob...@ocallahan.orgwrote: No problem at all. Can you do it? I need to get a WHATWG account :-). OK, I added the proposal here: http://wiki.whatwg.org/wiki/WorkerCanvas A couple of changes from the previous version: -- Added

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 4:17 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Oct 17, 2013 at 10:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard gl...@zewt.org wrote: Also, with the transferToImageBuffer approach, if you want to render

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 6:50 AM, Rik Cabanier caban...@gmail.com wrote: Extra methods on the canvas API: Promise setTaskScript(DOMString script); // can error be in promise? Promise executeTask(DOMString id, dictionary json, boolean synchronized = true); // Transferable elements allowed in

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

On Mon, Oct 21, 2013 at 4:46 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Oct 20, 2013 at 9:26 PM, Kyle Huey m...@kylehuey.com wrote: On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard gl...@bluegoji.com wrote: It must not be possible for the UI thread to detect whether present() did

Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

On Sun, Oct 20, 2013 at 5:33 PM, Glenn Maynard gl...@bluegoji.com wrote: Example: canvas id=canvas explicitpresent script var canvas = document.querySelector(#canvas); var worker = createWorker(); worker.postMessage({ cmd: init, canvas: canvas.getWorkerCanvas(), });

Re: [whatwg] Canvas in workers

On Sun, Oct 20, 2013 at 5:29 PM, Glenn Maynard gl...@zewt.org wrote: That's not the problem attachToCanvas tries to solve. It tries to solve rendering to multiple canvases, without requiring synchronization with the UI thread. I have a proposal for handling synchronization with DOM updates,

Re: [whatwg] Canvas in workers

Glenn, taking a step back for a bit, is there anything in https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal that you would actually object to? IOW, is there anything there that you would think is completely superfluous to the platform if all your proposals were to be adopted as well? Rob --

Re: [whatwg] Canvas in workers

On Sat, Oct 19, 2013 at 1:28 AM, Glenn Maynard gl...@zewt.org wrote: I'd like to hear thoughts on the context.attachToCanvas approach. I think it has important advantages over ImageBitmap: - ImageBitmap requires the user to call close(). If the user forgets, or doesn't know, or misses it

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 6:57 AM, Justin Novosad ju...@google.com wrote: Here is similar concept, but with an API more like WokerCanvas: The CanvasRenderingContext2D associated with a WorkerCanvas would only record draw commands, without executing them. The context would be write-only. When

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 10:56 AM, Justin Novosad ju...@google.com wrote: On Thu, Oct 17, 2013 at 5:50 PM, Rik Cabanier caban...@gmail.com wrote: Creating temporary canvases is still possible. I'm unsure how it would be different from a worker. An advantage would be that you can draw to the

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 12:32 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Oct 17, 2013 at 5:14 PM, Rik Cabanier caban...@gmail.com wrote: I don't remember multiple workers accessing the same canvas and I'm not quite sure what it means. I do remember a single (WebGL) context rendering

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 4:10 PM, Rik Cabanier caban...@gmail.com wrote: They would still have to wait for each other so the images are composited in-order. If you don't care about that, the 'synchronized' option would let you draw as soon as you exit the task (which is how Chrome always draws

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard gl...@zewt.org wrote: transferToImageBuffer looks like it would create a new ImageBuffer for each frame, so you'd need to add a close() method to make sure they don't accumulate due to GC lag, That's a good point. We will need something like

Re: [whatwg] Canvas in workers

On Thu, Oct 17, 2013 at 6:35 AM, Kenneth Russell k...@google.com wrote: Yes, right. That factory method is already spec'ed on the WorkerGlobalScope [1]. It actually returns a Promise, so presumably transferToImageBitmap would have to as well. The whole point of transferToImageBitmap is that

Re: [whatwg] Counterproposal for canvas in workers

On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier caban...@gmail.com wrote: The tasks themselves can also launch synchronized/unsynchronized subtasks with promises. A task is considered done if it exits and all its promises are fulfilled. It seems that tasks are like workers, but different, and

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

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

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

  1   2   3   4   5   6   7   >