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

Re: [Public WebGL] For review: ANGLE_timer_query extension



It doesn't really matter to the discussion what kind of abuse you will be able to make with an API-semantic if the precondition of it being usable at all due to performance constraints would be compromised by one or another flavor. You will need to resolve the technical feasability of either API flavor first before you're trying to evaluate their respective potential for abuse.


On Thu, Apr 4, 2013 at 9:37 AM, Gregg Tavares <gman@google.com> wrote:
So there's still another issue with polling. Even if we make it so you can't spin-wait and you can have to get result-available before checking the result you still end up with the issue that people will spam the browser by using 

    setInterval(checkQueries,0)

In order to effectively spin wait on the queries. They'll do this because it will be faster on some platforms.

I can certainly imagine code like this

      function onRequestAnimationFrame() {
            for each model {
                  start occlusion query
            }
            id = setInterval(processQueries, 0);
      }

      function processQueries() {
          for each query {
               if (result-available) {
                   if (not occluded) {
                       draw;
                   }
                   remove query
          }
          if no more queries {
             clearInterval(id)
             requestAnimationFrame(onRequestAnimationFrame);
          }
      }

On some implementations that may be faster even though is very bad for the browser.

Again, with callbacks that's impossible. The code to process queries as fast as possible becomes

       function onRequestAnimationFrame() {
            for each model {
                start occlusion query with callback for model
            }
       }

       function callback() {
          if (not occluded) {
             draw;
          }
          if no more queries {
             requestAnimationFrame(onRequestAnimationFrame);
          }
       }



       













On Wed, Apr 3, 2013 at 3:07 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares <gman@google.com> wrote:
In no way did I suggest you would need a full frame to do this testing. If you want to know if a certain type of rendering is slow you can test your various types of rendering, off screen, at initialization time and find out which ones are slow.
Unless you call gl.finish() which blocks you cannot test the time it took to render something. You do not want to call gl.finish() because it blocks. You may test performance characteristics up front, which tell you jack squat how long things will actually take to render troughout the use of the application. Timing how long something took to render, is the most accurate way to figure out how long it took to render.