[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL perf regression tests moved to GitHub; design still in flux



My suggestion to publish them on Github is to switch your default branch from master to gh-pages. Github will automatically rebuild the site ( http://KhronosGroup.github.com/WebGLPerf ) on every push to gh-pages.

Jon

On 2012-09-26, at 3:32 PM, Benoit Jacob <bjacob@mozilla.com> wrote:

> 
> Hi,
> 
> At Ken's request, I've moved our WebGL performance regression tests to
> GitHub:
> 
> https://github.com/KhronosGroup/WebGLPerf
> 
> This is a separate repository so we can more easily grant write access
> there.
> 
> Usual warning: these are only performance regression tests, not
> benchmarks (they would be terrible as benchmarks because they are as
> micro as micro-benchmarks get). Their purpose is to help implementers
> catch performance regressions in any given implementation. As more
> real-world applications are embracing WebGL, performance regressions can
> be as important to avoid as conformance regressions.
> 
> Could this be handled by the existing cron job that I suppose we have to
> make snapshots of these pages and serve them on HTTP? GitHub does not
> seem to allow automatically serving pages automatically from the repo.
> 
> Here is the online test runner:
> https://github.com/KhronosGroup/WebGLPerf/blob/master/index.html
> 
> Here is a sample test file, showing how easy it is to add one:
> https://github.com/KhronosGroup/WebGLPerf/blob/master/clear-varying-color.html
> 
> If you add one, don't forget to add it to tests.txt which determines
> which pages are loaded by the test runner.
> 
> Here is the test harness:
> https://github.com/KhronosGroup/WebGLPerf/blob/master/WebGLPerformanceTest.js
> 
> There are some non-trivial design changes coming in the near future, but
> I didn't want to let that block the move to GitHub. Points that are
> likely to change soon:
> 
> 1) Currently, tests can use either requestAnimationFrame, setTimeout(0),
> or postMessage to get their payload function called back. This leads to
> a rather convoluted and inelegant design in the test harness, which I
> would like to simplify.
> 
> 2) It's not clear that setTimeout(0) has any use. If one wants to
> measure stuff unrelated to compositing, postMessage should be at least
> as good as setTimeout(0) and often better in current browsers (not
> throttled). So we should be able to do with only RAF and postMessage.
> 
> 3) When using postMessage, one should measure only the time taken by the
> payload, instead of measuring the lapse of time between two consecutive
> callbacks.
> 
> Cheers,
> Benoit
> 
> 
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
> 


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------