As Ken notes in his later message, this is not the approach being considered by CSS shaders. I want to point out that, even if preventing timing of drawing was the approach, there would be no need to delay returns from drawArrays/Elements. They return essentially immediately and provide no useful information about rendering time; its the pipeline in action.Far as I could find the CSS shader spec has not yet decided on a restricting mechanism (timing or otherwise). Btw. I think that timing restrictions are not a good idea because it implies obeying a fixed time window for shader execution, which in turn implies that: 1) shaders *may* be aborted, which breaks apps. 2) drawArrays/Elements calls *will* be delayed from returning degrading app performance. To me those issues look worse than what they're trying to solve, i.e. the proverbial cure that kills the patient.
What would need to be done is to disable finish() and have the browser call requestAnimationFrame at regular intervals, e.g. at screen refresh. Unfortunately if some rendering takes more than the screen refresh interval, eventually something eventually has to give and at some point requestAnimationFrame will not be called on schedule. This permits a very coarse level of measurement such as whether the texture contains a pixel of a particular color. However these steps would prevent the Context exploit.
Most of the ways to make a shader artificially run for a very
long time could be stopped by better GLSL optimizers and loop
count limits. Simply aborting execution after a set time would
work for sure. Maybe these steps would be less objectionable to
those writing shaders for cross-origin textures than the
restrictions proposed by the CSS group.
Regards
-Mark
| Please note that, due to the integration of management operations following establishment of our new holding company, my e-mail address has changed to callow.mark<@>artspark<.>co<.>jp. I can receive messages at the old address for the rest of this year but please update your address book as soon as possible. |
NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.