OffscreenCanvas

2015-03-25T16:37:02Z

Jakearchibald: Adding use case

:''Provides more control over how canvases are rendered. This is a follow-on to the [[WorkerCanvas]] proposal and will be merged once agreement is reached.''

== Use Case Description ==

Feedback from web application authors using canvases have shown the need for the following controls:

* (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.
* (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.
* (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.
* (From adopters of the Push API): need to be able to dynamically create images to use as notification icons, such as compositing avatars, or adding an unread count

=== Current Limitations ===
''Explanation of why the current markup is insufficient.''

=== Current Usage and Workarounds ===
''Some evidence that this feature is desperately needed on the web. You may provide a separate examples page for listing these.''

=== Benefits ===

''Explanation of how and why new markup would be useful.''

=== Requests for this Feature ===

* <cite>[http://example.com Source]</cite> <blockquote><p>I would like this feature ...</p></blockquote>

== Web IDL ==

[Constructor(unsigned long width, unsigned long height)]
interface WorkerCanvas {
attribute unsigned long width;
attribute unsigned long height;
RenderingContext? getContext(DOMString contextId, any... arguments);
void toBlob(FileCallback? _callback, optional DOMString type, any... arguments);
ImageBitmap transferToImageBitmap();
};

WorkerCanvas implements Transferable;
ImageBitmap implements Transferable;

partial interface HTMLCanvasElement {
WorkerCanvas transferControlToWorker();
};

partial interface ImageBitmap {
void transferToImage(HTMLImageElement image);
};

== Proposed Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Processing Model ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

[[Category:Proposals]]

HTTP

2014-07-15T14:59:31Z

Jakearchibald:

This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.

== Content-Encoding ==

Under certain conditions this header needs to be stripped: http://hg.mozilla.org/mozilla-central/file/366b5c0c02d3/netwerk/protocol/http/nsHttpChannel.cpp#l4042

Not raised. Monkey patched in Fetch.

== Content-Length ==

In cases where Content-Length doesn't equal the actual content length, browsers truncate to the Content-Length value if it's smaller, but behaviour varies if Content-Length value is larger than actual content. Test results: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-49011736

== Content-Type parsing ==

Pretty sure I (Anne) raised this at some point. A trailing ";" after a MIME type is considered invalid, but works fine in all implementations.

mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.

'''Raised:''': http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

Potential replacement: http://mimesniff.spec.whatwg.org/#parsing-a-mime-type

== Redirects ==

For 301 and 302 redirects browsers uniformly ignore HTTP and use GET for the subsequent request if the initial request uses an unsafe method. (And the user is not prompted.)

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225

mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx

(Seems this is mostly solved now. Would still be good to explicitly require behavior here. Maybe in Fetch.)

== Location header: URLs ==

Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276

mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.

== Location header: duplicates ==

Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.

== Location header: fragment ==

https://bugzilla.mozilla.org/show_bug.cgi?id=1034819

== Content-Location header ==

Browsers cannot support this header.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg190

This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)

== Accept header ==

Accept header should preferably be done without spaces.

(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)

== Requiring two interoperable browser implementations ==

To prove that RFC 2616 can be implemented there should be two compatible implementations in browsers.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html

mnot: That'll happen when RFC723x go to full Standard.

== [Not an issue] Assume Vary: User-Agent ==

UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0114.html

:You may as well not have a cache if you do this. It's hard to find two users with the same User-Agent string if you try. It varies based on minor browser version, major OS version, and in old IE doesn't it vary based on installed plugins? Yes, some pages will break if you run a transparent caching proxy and don't vary based on UA, but it will be a small minority and somewhat random, and generally they'll fix themselves if you force-refresh. (Browsers send Cache-Control: no-cache when you force-refresh, which will skip a normally-configured cache.) Even if you vary based on UA, caching proxies will break some pages, because some sites serve incorrect caching headers and a caching proxy will make you hit these more often even in the single-user case. (E.g., hitting refresh will skip browser cache for the current page but not proxy cache, right?)<p>So basically, this is a performance vs. correctness tradeoff, and the correct answer for the vast majority of users is not to have a caching proxy at all. Some will want a caching proxy that serves them some incorrect pages. No one wants a caching proxy that varies based on UA, because then the cache will be useless. The only case I could think of where this might make sense is in an office with a homogeneous browser environment, which wants caching for its standard browsers (which all have the same UA string), but still wants to be relatively correct for people using Wi-Fi on their laptops with different browsers. But it's not something that makes any sense to require across the board. [[User:Aryeh Gregor|Aryeh Gregor]] 08:45, 17 October 2012 (UTC)

mnot: Yeah, that's a really bad idea.

[[Category:Spec_coordination]]

WHATWG Wiki - User contributions [en]

OffscreenCanvas

HTTP