On Wed, Dec 18, 2013 at 11:58 AM, Owen Taylor <otay...@redhat.com> wrote:
> From the partial backtrace posted on the bug, it looks like the code
> called in response to ::add-window is not drawing (which would be fairly
> surprising) but doing other GL operations - in the backtrace deleting a
> texture.

Going deeper into the trace, actually the call to delete the texture
is some code in our custom shell, running in a StWidget style_changed
handler. Maybe that is questionable. We've seen the hang in other
contexts too (e.g. window minimizing where mutter's idle_calc_showing
takes a server grab and then emits some signals to the shell), maybe
in less questionable cases. Either way I'm going to attempt to reduce
the server grabbing according to your comments - moreso than the
initial patch does.

> One thing that definitely should be noted is that we still have a server
> grab over everything when this code is called from
> meta_screen_manage_all_windows(). From a brief look, it appears to me
> that this happens *after* we initialize Javascript, set up signal
> connections, etc - so probably the only reason that your patch works for
> you is that the driver's internal swap-buffers thread isn't doing
> anything during initialization.

My patch does remove the meta_display_grab() call made by
meta_screen_manage_all_windows(). I'm not sure if it was necessary or
not, I just noticed that it calls meta_window_new_with_attrs() too and
decided to update it for the new semantics.

> This makes me less enthusiastic about the approach - we aren't avoiding
> calling application code with a server grab, we're just not doing it in
> the case that was causing a problem.

Yes, that patch was a quick attempt at making that hang go away. I'll
now see if I can do something more thorough where grabbing is done
over less scope and for well-documented reasons. I'll torture-test
too.

Thanks for your input.

Daniel
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

Reply via email to