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

Re: [Public WebGL] Resurrecting Update Scheduling

Kenneth Russell wrote:
Browsers supporting hardware compositing should automatically support
vsynced rendering. WebGL never renders directly to the screen; it
can't according to the HTML compositing model. If the browser uses a
GPU-based API to put the rendering results on the screen, and enables
vsync, then the WebGL output will be vsynced. Otherwise it's basically
impossible to get it to be.


In theory - shouldn't it be possible for browser implementors to optimize their compositing engine so that direct rendering can be done in applicable situations?

Example (pseudocode):

if all of the following are true:
  - nothing obscuring the 3d-canvas (no hovering semi-transparent divs etc)
  - canvas is 100% opaque (style-wise)
  - not clipped against browser client area
  - alternative take on the previous condition: if there are scrollbars, always run compositor
render directly
render with compositor (software/hardware)

Thus a canvas scaled to the size or less of the window will always render directly and still not
break the HTML compositing standard.

It would really mean an immense performance boost compared to the GPU->CPU->GPU train which
is abnormally slow considering what the GPU can do.

I also imagine a hardware compositor can get pretty complex, so would save some (for a game or immersive site)
unnecesarry CPU cycles.

It would be very very nice if something like this was implemented.
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: