[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





----- Original Message -----
> If I understand this correctly you're trying to make an end-run
> around the fact that you want to measure composite, yet don't want
> to be bothered by composite... or something like that.
> 
> 
> So in the performance there are two measure:
> 1) how much time (including gl.finish) does it take to clear the
> rendering queue and the buffer you're intending to composite is now
> filled

Right, that's the first measurement type that I outlined.  Just straight time elapsed in JS.

> 2) How much time does it take to actually composite this with the
> page.
> 
> 
> Isn't it that pretty much no matter what you put onto your buffer,
> composite will take the the same time? I mean, it can be black, or
> transparent, or white, or full of noise, doesn't matter. Every pixel
> gets blended.

This is corect.

> So what you do during frame-rendering actually has 0
> impact to regressions in composition, so these are two completely
> different topics. For frame render time, gl.finish and the high perf
> timer should be sufficient to detect FPS/composite/rAf independent
> times. And to measure compositing, well, maybe add some API that
> lets you measure that specifically. Could be interesting anways for
> app developers as well, to know how much time they have left for
> actually doing stuff per frame.

Yup -- it's not that we don't want to measure composite, we're making an end-run around the fact that there exists no API for measuring composite.  That API could also be somewhat complicated to define, because each browser could have a very different idea of what it actually means to composite.  So, instead, I'm more interested in treating it as "overhead" -- I want to measure how much overhead a browser adds to each frame.  This could be compositing overhead, it could be function call/JS bridge overhead, etc.  That's where the second attempt comes into play, and it sounds like what gregg's already tried to implement.

    - Vlad

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