Hi Min,
On Sat, Apr 28, 2018 at 11:56 AM He, Min wrote:
> Hi, Tomasz
> On 4/27/2018 5:01 PM, Tomasz Figa wrote:
> > Hi Min,
> >
> > On Fri, Apr 27, 2018 at 11:36 AM Min He wrote:
> >
> >> To avoid blocking other EGL calls, release the display mutex before
> >> calling update_buffers(), which w
Hi, Tomasz
On 4/27/2018 5:01 PM, Tomasz Figa wrote:
Hi Min,
On Fri, Apr 27, 2018 at 11:36 AM Min He wrote:
To avoid blocking other EGL calls, release the display mutex before
calling update_buffers(), which will call droid_window_dequeue_buffer().
The lock appears like below:
1. Consumer thr
On 27.04.2018 12:01, Tomasz Figa wrote:
Hi Min,
On Fri, Apr 27, 2018 at 11:36 AM Min He wrote:
To avoid blocking other EGL calls, release the display mutex before
calling update_buffers(), which will call droid_window_dequeue_buffer().
The lock appears like below:
1. Consumer thread: update
Hi Min,
On Fri, Apr 27, 2018 at 11:36 AM Min He wrote:
> To avoid blocking other EGL calls, release the display mutex before
> calling update_buffers(), which will call droid_window_dequeue_buffer().
> The lock appears like below:
> 1. Consumer thread: updateTexImage() -> updateAndReleaseLocked(
As discussed offline, this is similar to commit 1ea233c. LGTM;
Reviewed-by: Tapani Pälli
On 04/27/2018 05:17 AM, Min He wrote:
To avoid blocking other EGL calls, release the display mutex before
calling update_buffers(), which will call droid_window_dequeue_buffer().
The lock appears like belo
To avoid blocking other EGL calls, release the display mutex before
calling update_buffers(), which will call droid_window_dequeue_buffer().
The lock appears like below:
1. Consumer thread: updateTexImage() -> updateAndReleaseLocked() ->
syncForReleaseLocked() -> eglDupNativeFenceFDANDROID() ->
_eg
