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
_______________________________________________
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
