[waffle] [PATCH 0/7] nacl backend implementation

[Chad Versace]

On 02/05/2015 04:45 AM, Tapani wrote:
> On 02/05/2015 09:47 AM, Tapani Pälli wrote:
>> 
>> On 02/03/2015 10:07 PM, Chad Versace wrote:
>>> It seems that two solutions are available:
>>> 
>>> S1. Provide waffle_set_swap_buffers_callback().
>>> 
>>> S2. On Waffle's NaCl backend, implement waffle_swap_buffers() to
>>> block until the back buffer has been composited onto the web
>>> page. (I believe this is possible to implement without a worker
>>> thread).
>> 
>> I guess it is possible but not without introducing extra
>> latency/slowness for the application thread which I was trying to
>> avoid. Ideally app could continue doing something else while swap
>> goes on.

I also don't want Waffle to force latency onto the app.

I originally though that Solution2 (a blocking swapbuffers on NaCl)
did not force any latency, as long as the application created a separate
"presentation" thread that performed the swap buffer calls. But I no
longer have that opinion. Maintaining a seprate "presentation" thread
that does swapbuffer calls and a "rendering" thread that does the real
rendering is difficult to do safely in OpenGL, because OpenGL is inherently
a single-threaded API. And I've heard that some drivers are fundamentally
broken with respect to multi-threading.

So, I agree with you now. If waffle_window_swap_buffers() blocks, that
*will* force latency onto the NaCl app unless Waffle also provides
some alternative non-blocking way to swap buffers, because we can't reasonably
expect applications to avoid the latency by creating a separate presentation
thread and suffering through the inevitable OpenGL headaches.

One of the design goals I have in Waffle is that "the application's use
of Waffle should vary as little as possible across platforms". If, to
obtain correct rendering behavior, Waffle requires users on NaCl to
use a swapbuffer callback but on non-NaCl platforms the callback is
unneeded, then then I feel such a callback violates the design goal.
That's the main reason I'm opposed to the callback.

I'd like the default behavior of waffle_window_swap_buffers() on NaCl
to be blocking behavior due the design goal above. The default behavior
should give correct rendering like it does on all other platforms.
Then, in follow-up patches, we can start working on providing non-blocking
solutions, either with a callback or cookie mechanism. I don't want to
lightly add a callback mechanism as part of this series, because
implementing it correctly, in a way compatible with non-NaCl usage,
will require adding callback queue and dispatch to Waffle, a non-trivial
task.

Once the NaCl patches landed, with blocking swapbuffers, then let's
have a realtime conversation on how to implement the non-blocking
alternative.

> Having experimented this for some time with this I don't think this
> is possible to implement. Problem is that I can't wait in the main
> thread for the callback to be called (blocking somewhere within
> waffle_swap_buffers), the event dispatcher never gets run and there
> is no API to 'flush event queue' or 'run single iteration of event
> dispatcher'. There is way to get pp::MessageLoop of the main thread
> but you can just post more work to it. I vote for the thread, I don't
> find problems with it :)

Thanks for explaining that. I understand now why the helper thread is needed
to implement a blocking swap buffers.

I have two more experiments that may be worth doing:
- If you pass PP_GRAPHICS3DATTRIB_SWAP_BEHAVIOR=PP_GRAPHICS3DATTRIB_BUFFER_DESTROYED
  to PPB_Graphics3D::Create, then does  PPB_Graphics3D::SwapBuffers behave more
  traditionally? That is, if you begin rendering immediately after it returns,
  do you get correct rendering? I ask this because I hope NaCl implements BUFFER_DESTROYED
  with double- or triple-buffering.
- The same question, but passing the attribute to PPB_Graphics3D::SetAttribs instead.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20150206/b9d789d6/attachment.sig>