https://wiki.whatwg.org/api.php?action=feedcontributions&user=Esprehn&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T15:48:34ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9527Navigator HW Concurrency2014-05-02T21:47:03Z<p>Esprehn: /* API */</p>
<hr />
<div>Proposed navigator.cores API for smarter Worker pool allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of user-accessible logical processors.<br />
<br />
The intended use for the API is to help developers make informed decisions regarding the size their worker threadpools to perform CPU-intensive parallel algorithms.<br />
<br />
Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.<br />
<br />
* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code>&lt;a download&gt;</code>) without having to prompt the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing with worker threads in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores.<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode, they must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu<br />
<br />
The number must be >= 1.<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCores {<br />
readonly attribute unsigned long cores;<br />
};<br />
</pre><br />
<br />
== Privacy concerns ==<br />
<br />
System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. Chrome also exposes it through PNacl.<br />
<br />
== Appendix ==<br />
<br />
An open source O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9523Navigator HW Concurrency2014-05-02T21:09:22Z<p>Esprehn: /* Privacy concerns */</p>
<hr />
<div>Proposed navigator.cores API for efficient Worker allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of user-accessible logical processors.<br />
<br />
The intended use for the API is to help developers appropriately size their worker threadpools for the user's system in order to perform CPU-intensive parallel algorithms.<br />
<br />
Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.<br />
<br />
* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code>&lt;a download&gt;</code>) without having to prompt the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode, they must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCores {<br />
readonly attribute unsigned long cores;<br />
};<br />
</pre><br />
<br />
== Privacy concerns ==<br />
<br />
System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. Chrome also exposes it through PNacl.<br />
<br />
== Appendix ==<br />
<br />
An O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9522Navigator HW Concurrency2014-05-02T21:08:33Z<p>Esprehn: /* API */</p>
<hr />
<div>Proposed navigator.cores API for efficient Worker allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of user-accessible logical processors.<br />
<br />
The intended use for the API is to help developers appropriately size their worker threadpools for the user's system in order to perform CPU-intensive parallel algorithms.<br />
<br />
Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.<br />
<br />
* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code>&lt;a download&gt;</code>) without having to prompt the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode, they must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCores {<br />
readonly attribute unsigned long cores;<br />
};<br />
</pre><br />
<br />
== Privacy concerns ==<br />
<br />
System core count is public information as it is already accessible with the polyfill in the appendix. If you believe core count is a privacy leak, then the only solution is to completely remove web worker threads from the specification, as a timing attack on threadpool performance will always be possible otherwise.<br />
<br />
== Appendix ==<br />
<br />
An O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9521Navigator HW Concurrency2014-05-02T21:08:11Z<p>Esprehn: /* API */</p>
<hr />
<div>Proposed navigator.cores API for efficient Worker allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of user-accessible logical processors.<br />
<br />
The intended use for the API is to help developers appropriately size their worker threadpools for the user's system in order to perform CPU-intensive parallel algorithms.<br />
<br />
Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.<br />
<br />
* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code>&lt;a download&gt;</code>) without having to prompt the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode, they must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
On getting the |cores| property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCores {<br />
readonly attribute unsigned long cores;<br />
};<br />
</pre><br />
<br />
== Privacy concerns ==<br />
<br />
System core count is public information as it is already accessible with the polyfill in the appendix. If you believe core count is a privacy leak, then the only solution is to completely remove web worker threads from the specification, as a timing attack on threadpool performance will always be possible otherwise.<br />
<br />
== Appendix ==<br />
<br />
An O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9520Navigator HW Concurrency2014-05-02T21:05:40Z<p>Esprehn: /* Abstract */</p>
<hr />
<div>Proposed navigator.cores API for efficient Worker allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of user-accessible logical processors.<br />
<br />
The intended use for the API is to help developers appropriately size their worker threadpools for the user's system in order to perform CPU-intensive parallel algorithms.<br />
<br />
Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.<br />
<br />
* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code>&lt;a download&gt;</code>) without having to prompt the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode, they must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCores {<br />
readonly attribute unsigned long cores;<br />
};<br />
</pre><br />
<br />
<br />
== Privacy concerns ==<br />
<br />
System core count is public information as it is already accessible with the polyfill in the appendix. If you believe core count is a privacy leak, then the only solution is to completely remove web worker threads from the specification, as a timing attack on threadpool performance will always be possible otherwise.<br />
<br />
== Appendix ==<br />
<br />
An O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=RequestAutocomplete&diff=9500RequestAutocomplete2014-04-04T01:29:43Z<p>Esprehn: </p>
<hr />
<div>requestAutocomplete proposed spec (as implemented in Chromium)<br />
<br />
This document contains a preliminary specification of the requestAutocomplete feature that allows developers to request that the browser fill a form with information based on the autocomplete attributes on the form controls.<br />
<br />
== Issues ==<br />
<br />
This should really use a promise: http://dom.spec.whatwg.org/#promises (http://crbug.com/343630).<br />
<br />
== Interfaces Additions== <br />
<br />
interface '''HTMLFormElement''' : HTMLElement {<br />
...<br />
void requestAutocomplete();<br />
};<br />
<br />
enum AutoCompleteErrorReason {<br />
"",<br />
"cancel",<br />
"disabled",<br />
"invalid"<br />
};<br />
<br />
[Constructor(DOMString type, optional AutocompleteErrorEventInit eventInitDict)]<br />
interface '''AutocompleteErrorEvent''' : Event {<br />
readonly attribute AutoCompleteErrorReason reason;<br />
};<br />
<br />
dictionary '''AutocompleteErrorEventInit''' : EventInit {<br />
AutoCompleteErrorReason reason = "";<br />
};<br />
<br />
== Algorithms ==<br />
<br />
When the '''requestAutocomplete'''() method is invoked, the user agent must run the following steps:<br />
<br />
# If we are not allowed to show a popup then asynchronously fail with the reason "disabled" and abort these steps.<br />
# If the ''requestAutocompleteIsActive'' flag is true or the form element's autocomplete attribute evaluates to “off” then asynchronously fail with the reason "disabled" and abort these steps.<br />
# Optionally asynchronously fail with the reason "disabled" and abort these steps.<br />
#: (For example the user agent may give the user an option to ignore all autocomplete requests.)<br />
# Set the ''requestAutocompleteIsActive'' flag to true.<br />
# Let the pending autofill set be an empty set of autocomplete tuples of the form <br />
#: ( autocomplete attribute: string, input: Element )<br />
# For each element that has this form element as its form owner add it to the pending autocomplete set with its attribute values if:<br />
#* The autocomplete attribute is specified for its element type.<br />
#* The autocomplete attribute parses to a valid value.<br />
# Asynchronously request autocomplete from the user agent for the pending auto fill set for this form element.<br />
<br />
When the user agent is said to request autocomplete for a form element it should run the following steps:<br />
<br />
# Let the autofill set be the set of autocomplete tuples that were passed into this algorithm.<br />
# Optionally asynchronously fail with the reason "cancel" and abort these steps. (For example if the user cancels the request.)<br />
# For each tuple in the autofill set:<br />
#: a. Skip this tuple if the input's attribute value for autocomplete is different than the one stored in the tuple.<br />
#: b. Skip this tuple if the form owner of the input is not this form element.<br />
#: c. Autofill the input following the autocomplete rules but allowing the input to suffer from a pattern mismatch.<br />
# Statically validate the constraints and:<br />
#: a. If the result is negative asynchronously fail with the reason "invalid".<br />
#: b. If the result is positive fire a simple event named "autocomplete" that bubbles on the form element.<br />
# Set the requestAutocompleteIsActive flag to false.<br />
<br />
When the user agent is said to asynchronously fail with a reason it queue an event to fire on the form element currently being operated on of a new AutocompleteErrorEvent with the type "autocompleteerror" and the reason specified.<br />
<br />
[[Category:Proposals]]</div>Esprehnhttps://wiki.whatwg.org/index.php?title=RequestAutocomplete&diff=9067RequestAutocomplete2013-03-12T23:40:33Z<p>Esprehn: Created page with "requestAutocomplete proposed spec (as implemented in Chromium) This document contains a preliminary specification of the requestAutocomplete feature that allows developers to..."</p>
<hr />
<div>requestAutocomplete proposed spec (as implemented in Chromium)<br />
<br />
This document contains a preliminary specification of the requestAutocomplete feature that allows developers to request that the browser fill a form with information based on the autocomplete attributes on the form controls.<br />
<br />
== Interfaces Additions== <br />
<br />
interface '''HTMLFormElement''' : HTMLElement {<br />
...<br />
void requestAutocomplete();<br />
}<br />
<br />
[Constructor(DOMString type, optional AutocompleteErrorEventInit eventInitDict)]<br />
interface '''AutocompleteErrorEvent''' : Event {<br />
readonly attribute DOMString reason;<br />
}<br />
<br />
dictionary '''AutocompleteErrorEventInit''' : EventInit {<br />
DOMString reason = “”;<br />
};<br />
<br />
== Algorithms ==<br />
<br />
When the '''requestAutocomplete'''() method is invoked, the user agent must run the following steps:<br />
<br />
# If we are not allowed to show a popup then asynchronously fail with the reason “disabled” and abort these steps.<br />
# If the ''requestAutocompleteIsActive'' flag is true or the form element’s autocomplete attribute evaluates to “off” then asynchronously fail with the reason “disabled” and abort these steps.<br />
# Optionally asynchronously fail with the reason “disabled” and abort these steps.<br />
#: (For example the user agent may give the user an option to ignore all autocomplete requests.)<br />
# Set the ''requestAutocompleteIsActive'' flag to true.<br />
# Let the pending autofill set be an empty set of autocomplete tuples of the form <br />
#: ( autocomplete attribute: string, input: Element )<br />
# For each element that has this form element as its form owner add it to the pending autocomplete set with its attribute values if:<br />
#* The autocomplete attribute is specified for its element type.<br />
#* The autocomplete attribute parses to a valid value.<br />
# Asynchronously request autocomplete from the user agent for the pending auto fill set for this form element.<br />
<br />
When the user agent is said to request autocomplete for a form element it should run the following steps:<br />
<br />
# Let the autofill set be the set of autocomplete tuples that were passed into this algorithm.<br />
# Optionally asynchronously fail with the reason “cancel” and abort these steps. (For example if the user cancels the request.)<br />
# For each tuple in the autofill set:<br />
#: a. Skip this tuple if the input’s attribute value for autocomplete is different than the one stored in the tuple.<br />
#: b. Skip this tuple if the form owner of the input is not this form element.<br />
#: c. Autofill the input following the autocomplete rules but allowing the input to suffer from a pattern mismatch.<br />
# Statically validate the constraints and:<br />
#: a. If the result is negative asynchronously fail with the reason “invalid”.<br />
#: b. If the result is positive fire a simple event named “autocomplete” on the form element.<br />
# Set the requestAutocompleteIsActive flag to false.<br />
<br />
When the user agent is said to asynchronously fail with a reason it queue an event to fire on the form element currently being operated on of a new AutocompleteErrorEvent with the type “autocompleteerror” and the reason specified.<br />
<br />
[[Category:Proposals]]</div>Esprehn