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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
