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

[Tapani Pälli]

On 02/06/2015 11:58 PM, Chad Versace wrote:
> 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.

Right, it can be rather painful. Maybe some non-blocking option can be 
planned as the future API, if not with traditional GL then perhaps with 
glNext.

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

Yes, I agree on this point and respect this decision. Portability and 
ease of use should be the main driver here, it feels bad to introduce 
additional API for just one backend.

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

OK, I'll try to get blocking behaviour to work. I'm a bit surprised that 
there seems no way to 'flush pending events' or something like this in 
NaCl which would make this much easier to implement.

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

Thanks, I'll try these out!

// Tapani