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 encourage > > browser vendors to look at

Re: [whatwg] VIDEO and pitchAdjustment

On Wed, Sep 2, 2015 at 5:30 AM, David Singer wrote: > On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25 > fps, > > keyframe every 10s. Storing all those frames takes 250 x 4096 x 2160 x 2 > &

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 posters above > claim - you

Re: [whatwg] VIDEO and pitchAdjustment

On Sat, Aug 29, 2015 at 8:18 AM, James Ross 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 testing. > That's not

Re: [whatwg] VIDEO and pitchAdjustment

On Fri, Aug 28, 2015 at 6:02 AM, Garrett Smith 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 adjust to the speed

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 11:02 PM, Ashley Gullen 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 a > similar amo

Re: [whatwg] Worker requestAnimationFrame

On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick wrote: > On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad wrote: > >> On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers wrote: >> >>> Sounds great to me. I agree this is an important scenario. *Ian*, >> >> >>> thoughts? >> >> > I would certainly like to s

[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 v

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

On Thu, Jul 16, 2015 at 8:44 PM, Philip Jägenstedt 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 hnysnenh hhe uresyf t

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

On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt wrote: > On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan > wrote: > > On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt > > wrote: > >> > >> Basically a "I trust the browser to decide and p

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

On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt 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 HAVE_ENOUGH_DATA

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

On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt 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", to rule out

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

On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt wrote: > I see, is this a policy that's applied even with a single 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 internally? Presto actual

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

On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt 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 many elemen

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 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. > OK. > >

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

On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt wrote: > On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan > wrote: > > > On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt > > wrote: > > > >> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan &

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

On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt wrote: > On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan > wrote: > > In Gecko, doesn't fire "canplay". This is > > allowed (encouraged, even) by the spec, since we can efficiently satisfy > > p

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

On Mon, Jun 15, 2015 at 12:40 PM, Daniel Holbert wrote: > There was a suggestion on one of the bugs that we simply ignore > 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 vendors/spec-authors' o

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

In Gecko, 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 may be counterintuiti

Re: [whatwg] High-density canvases

On Thu, Apr 16, 2015 at 7:07 AM, Justin Novosad 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, which I document

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 ImageBitmap's

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

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

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

On Tue, Apr 14, 2015 at 9:03 AM, Justin Novosad wrote: > On Sun, Apr 12, 2015 at 5:41 PM, Robert O'Callahan > wrote: > > > On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell wrote: > > > >> > >> 3. Are onload and onerror events fired? This question a

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

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

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

On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell 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 spec ter

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

On Sat, Apr 11, 2015 at 2:18 AM, Justin Novosad 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 > through? In ca

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

On Thu, Apr 9, 2015 at 9:44 AM, Kenneth Russell wrote: > On Tue, Apr 7, 2015 at 6:42 PM, Robert O'Callahan > wrote: > > As far as I can tell, the only significant difference between > > this and WorkerCanvas is using an HTMLCanvasElement "bitmaprenderer" as

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

On Wed, Apr 8, 2015 at 11:41 AM, Kenneth Russell 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 browser i

Re: [whatwg] Recorder audio and save to server

On Tue, Apr 7, 2015 at 11:40 PM, Ashley Gullen 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 > long and the

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. https://developer

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

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

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

On Thu, Mar 26, 2015 at 8:40 AM, Justin Novosad 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 right > now, bu

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

On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren wrote: > On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan > 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

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 J

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

On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier wrote: > On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan > wrote: > > > On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier > wrote: > > > >> Justin is worried that in order to make this asynchronous, Chrome has t

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

On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier wrote: > Justin is worried that in order to make this asynchronous, Chrome has to > create a snapshot of the canvas bits which is slow if it resides on the > GPU. > Of course, his workaround to use getImageData is just as slow since it has > to do the

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

On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier 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 owohooo oioso oaono

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

On Sat, Mar 21, 2015 at 3:38 PM, Rik Cabanier 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 WorkerCanvas.

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

On Sat, Mar 21, 2015 at 1:13 AM, Jake Archibald 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 > notification ( > https://not

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

On Wed, Nov 5, 2014 at 3:46 AM, Martin Hoernig 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 at

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

On Tue, Nov 4, 2014 at 10:54 AM, Robert O'Callahan 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 dat

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

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

On Thu, Oct 30, 2014 at 9:15 AM, Peter Kasting wrote: > If browsers had to retry open "find"s 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 > page. Is th

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

On Tue, Oct 28, 2014 at 1:13 AM, David Kendal wrote: > On 27 Oct 2014, at 12:08, Robert O'Callahan 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 to >

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

On Sun, Oct 26, 2014 at 2:30 AM, David Kendal wrote: > Hi, > > > 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 this yea

Re: [whatwg] Support filters in Canvas

On Tue, Sep 30, 2014 at 12:45 AM, Rik Cabanier 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 we restrict the

Re: [whatwg] Support filters in Canvas

On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier 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 into the one spe

Re: [whatwg] Notifications and service workers

Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking : > On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson > wrote: > >> * Dropping the close event. > >> > >> I've been wondering myself whether it's valuable to support this. Like > >> Tab, I'm not aware

Re: [whatwg] Notifications: the ability to specify notifications behavior

On 09/06/2014 03:02 AM, Anne van Kesteren wrote: Do you mean the Notifications API? As with most standards we're not really touching the UI space at the moment. That's what I meant. I filed an issue on the github page for that https://github.com/whatwg/notifications/issues/24. Robert

Re: [whatwg] Notifications: the ability to specify notifications behavior

On 08/13/2014 04:36 PM, Jonas Sicking wrote: On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar wrote: Concerning web notifications, it would be very helpful for content and web apps to have a way of specifying the behavior their notifications should have. For instance, a chat client may not

Re: [whatwg] Notifications: the ability to specify notifications behavior

On 08/13/2014 04:36 PM, Jonas Sicking wrote: > On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar wrote: >> Concerning web notifications, it would be very helpful for content and web >> apps >> to have a way of specifying the behavior their notifications should have. &g

[whatwg] Notifications: the ability to specify notifications behavior

-agent to determine whether it wants to honor these behaviors (based on platform support, user settings, or even general user experience). I'd appreciate any feedback on this, name suggestions or new useful options. [1] lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/252648.html Thanks, Robert

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 wi

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 oa

Re: [whatwg] High-density canvases

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

Re: [whatwg] High-density canvases

On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad 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 anyone would a

Re: [whatwg] High-density canvases

On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad 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 renderedPixelWidth/Height returns th

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan 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 &#x

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan wrote: > On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad 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

Re: [whatwg] High-density canvases

On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad 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 a > way that d

Re: [whatwg] High-density canvases

On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier 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 > renderedsizec

Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. 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 showing up > in the fir

Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan 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.r&qu

Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell 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 proceed? W

Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell wrote: > It's hard to predict. A more general API would be better than a > canvas-specific one, assuming it solves the problem. getBoxQuads can > return different types of CSS boxes (content, padding, border, margin) > -- will it be obvious to web

Re: [whatwg] High-density canvases

On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell 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 to device p

Re: [whatwg] High-density canvases

On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad 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 > the "preferre

Re: [whatwg] High-density canvases

On Fri, Jun 20, 2014 at 2:54 AM, Stephen White wrote: > I assume that the size change event would fire: > >- on browser page zoom >- on pinch-zoom >- when a CSS animation (e.g., scale) changes the canvas size in CSS >pixels > > For browsers that implement the latter two off the ma

Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan wrote: > On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote: > >> I am currently trying an experimental approach where canvases that are >> drawn to, but never read from (no toDataURL or getImageData calls) have >

Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad 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 must be a cli

[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 attrib

Re: [whatwg] High-density canvases

[Resurrecting old thread] On Tue, Sep 10, 2013 at 12:00 PM, Ian Hickson 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 trigger

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

On Sat, May 31, 2014 at 3:44 AM, Justin Novosad 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 make them

Re: [whatwg] ImageBitmap feature requests

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

Re: [whatwg] addPath and CanvasPathMethods

On Fri, Mar 21, 2014 at 8:15 AM, Justin Novosad 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 take advantag

Re: [whatwg] Hit regions and events

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

Re: [whatwg] Hit regions and events

On Wed, Mar 5, 2014 at 12:53 PM, Ian Hickson 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 validly

Re: [whatwg] Proposal: requestBackgroundProcessing()

On Fri, Feb 21, 2014 at 11:32 AM, Ashley Gullen 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 is > planned, I

Re: [whatwg] HTML rendering

BTW, some exploratory testcases are at http://people.mozilla.org/~roc/fieldsets.html. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,

[whatwg] HTML 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 of

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 mor

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 Sun, Nov 3, 2013 at 3:03 PM, Rik Cabanier wrote: > On Sat, Nov 2, 2013 at 1:01 AM, Robert O'Callahan wrote: > >> Does this mean that ctx.currentPath != ctx.currentPath? >> > > Yes > > >> That's bad! >> > > Why would it be bad (apart

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

On Sat, Nov 2, 2013 at 1:01 PM, Rik Cabanier 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 Path currentPat

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 canv

Re: [whatwg] Canvas in workers

On Tue, Oct 22, 2013 at 10:44 PM, Robert O'Callahan wrote: > 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 ImageBitmap.tran

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.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr at

Re: [whatwg] Canvas in workers

On Tue, Oct 22, 2013 at 7:31 PM, Kenneth Russell 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

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 wrote: > On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan >wrote: > > > This code actually does something potentially useful which can't easily > be > > done with attachToCanvas: generating a series of images as

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 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 > lots of bac

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 Sun, Oct 20, 2013 at 5:29 PM, Glenn Maynard 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, but I'll p

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 wrote: > Example: > > > > var canvas = document.querySelector("#canvas"); > var worker = createWorker(); > worker.postMessage({ > cmd: "init", > canvas: canvas.getWorkerCanvas(), > }); > > worker.onmessage = function(e) > { > // The wor

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 wrote: > On Sun, Oct 20, 2013 at 9:26 PM, Kyle Huey wrote: > > > On Sun, Oct 20, 2013 at 11:33 PM, Glenn Maynard >wrote: > > > >> It must not be possible for the UI thread to detect whether present() > did > >> anything--if there's no frame in the

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 6:50 AM, Rik Cabanier 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 dictionary > >

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 4:17 PM, Glenn Maynard wrote: > On Thu, Oct 17, 2013 at 10:25 PM, Robert O'Callahan >wrote: > > On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard wrote: > >> Also, with the "transferToImageBuffer" approach, if you want to render >

Re: [whatwg] Canvas in workers

On Sat, Oct 19, 2013 at 1:28 AM, Glenn Maynard 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 in some c

Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard 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 that. It wou

  1   2   3   4   5   6   7   8   9   >