This ensures framebuffers are implicitly allocated when querying the
width, height or viewport width/height if the framebuffer's size is
currently unknown. The plan is to allow texture backends to defer
calculating the size of textures until they are allocated which in turn
means we won't know the size of offscreen framebuffers until the texture
has been allocated. Potentially we could be more specific about this in
the future and only ensure the texture is allocated, but for now it will
be simplest to just ensure the framebuffer is allocated.
Note: in the case of onscreen buffers which are always initialized with
a requested size we are careful to avoid triggering an allocation when
this is queried otherwise we will see recursion when the winsys code
queries the requested size during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f4b612f1b75e043f1852b9a32368cc37ab89308b)
Since we are planning on deferring more texture allocation work this
makes sure we don't query whether a texture is sliced until we know it
has been allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit b742638a1ce581f5a2c9f15907361c3b0c1b178c)
This removes cogl_framebuffer_get_color_format() since the actual
internal format isn't strictly controlled by us. CoglFramebuffer::format
has been renamed to ::internal_format to make it clearer that it only
really represents the premultiplication status.
The plan is to make most of the work involved in creating a texture
happen lazily when allocating so this patch also changes
_cogl_framebuffer_init() to not take a format argument anymore since we
won't know the format of offscreen framebuffers until the framebuffer is
allocated, after the corresponding texture has been allocated. In the
case of offscreen framebuffers we now update the framebuffer
internal_format during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8cc9e1c8bd2fac8b2a95087249c23c952d5e379f)
Note: Since we can't break API compatibility on the 1.x branch this
actually keeps the cogl_framebuffer_get_color_format() api but moves it
into a new deprecated/cogl-framebuffer-deprecated.c file and it now
returns the newly name ::internal_format.
This grab was added in commit caf43a123f40d3a68599ac5453a79759b828e8f0
https://bugzilla.gnome.org/show_bug.cgi?id=381127
to minimize window flickering when switching workspaces.
While this grab is held, some signals are emitted to the shell,
which can lead to deadlocks (reproduced under Mali binary OpenGLESv2
drivers).
Now that we are a compositing window manager, we do not have to
worry about flickers, this grab should no longer be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=721709
This grab was added in commit caf43a123f40d3a68599ac5453a79759b828e8f0
https://bugzilla.gnome.org/show_bug.cgi?id=381127
to minimize window flickering when switching workspaces.
While this grab is held, some signals are emitted to the shell,
which can lead to deadlocks (reproduced under Mali binary OpenGLESv2
drivers).
Now that we are a compositing window manager, we do not have to
worry about flickers, this grab should no longer be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=721709
Under some circumstances, for example when the display controller driver
doesn't report back the correct EDID, or under VirtualBox, Mutter
returns suboptimal strings for an output display name, leading to funny
labels like 'Unknown 0"', or '(null) 0"' in the Settings panel.
This commit improves our heuristic in three ways:
- we now avoid putting inches in the display name if either dimension is
zero
- we use the vendor name in case we're not able to lookup its PnP id
from the database. Previously we would have passed over '(null)'
- as a special edge-case, when neither inches nor vendor are known, we
use the string 'Unknown Display'
Finally, we make the combined vendor + inches string translatable, as
different languages might want to move the size part of the string to a
position different than the end.
https://bugzilla.gnome.org/show_bug.cgi?id=721674
Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.
During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.
When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).
The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.
Now that there are no grabs we don't have to worry about explicitly calling
display_notify_window after grabs have been dropped. Fold that into
meta_window_new_shared().
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The return code of XGetWindowAttributes() indicates whether an error
was encountered or not. There is no need to specifically check the error
trap.
The trap around XAddToSaveSet() was superfluous. We have a global error
trap to ignore any errors here, and there is no need to XSync() as GDK
will later ignore the error asynchronously if one is raised.
Also move common error exit path to an error label.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
In meta_screen_manage_all_windows() we can use our own stack
tracker to get the list of windows - no need to query X again.
A copy is needed because the stack gets modified as part of the loop.
Specifically, meta_stack_tracker_get_stack() at this time returns the
predicted stack, and meta_window_new() performs a few operations
(e.g. framing) which cause immediate changes to the predicted stack.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.
But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().
Remove the unnecessary grab.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
Server grabs are not as evil as you might expect, but there is agreement
in that their usage should be limited.
Server grabs can cause things to go rather wrong when mutter emits
a signal while it has grabbed the server. If the receiver of that signal
waits for a synchronous action performed by another client, then you
have a deadlock. This happens with Mali binary GLESv2 drivers :(
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.
As that doesn't happen any more, we can clean up. No functional changes.
Suggested by Owen Taylor.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.
During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.
When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).
The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The return code of XGetWindowAttributes() indicates whether an error
was encountered or not. There is no need to specifically check the error
trap.
The trap around XAddToSaveSet() was superfluous. We have a global error
trap to ignore any errors here, and there is no need to XSync() as GDK
will later ignore the error asynchronously if one is raised.
Also move common error exit path to an error label.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
In meta_screen_manage_all_windows() we can use our own stack
tracker to get the list of windows - no need to query X again.
A copy is needed because the stack gets modified as part of the loop.
Specifically, meta_stack_tracker_get_stack() at this time returns the
predicted stack, and meta_window_new() performs a few operations
(e.g. framing) which cause immediate changes to the predicted stack.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.
But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().
Remove the unnecessary grab.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The bug that prevented MESA_copy_sub_buffer to work for swrast /
llvmpipe got fixed in mesa 10.1 git so enable it for mesa 10.1+.
https://bugzilla.gnome.org/show_bug.cgi?id=721450
When landing the patch, it was tweaked to #include "cogl-version.h" to
avoid a compiler warning about COGL_VERSION_ENCODE being implicitly
defined. -- Robert Bragg
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e7e216b1d3d151acf3fed619bd759692a989b4b4)
Server grabs are not as evil as you might expect, but there is agreement
in that their usage should be limited.
Server grabs can cause things to go rather wrong when mutter emits
a signal while it has grabbed the server. If the receiver of that signal
waits for a synchronous action performed by another client, then you
have a deadlock. This happens with Mali binary GLESv2 drivers :(
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.
As that doesn't happen any more, we can clean up. No functional changes.
Suggested by Owen Taylor.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
This fixes a mistake in commit 637728dd89d51bc28 that was meant to fix
yv12/i420 support but when the patch was updated based on review to use
COGL_PIXEL_FORMAT_A instead of COGL_PIXEL_FORMAT_G the corresponding
glsl code wasn't also updated to sample the .a component.
(cherry picked from commit a02c55105c705471866df2d306879d8616289f2a)
As logind can give us a new FD at any time when it resumes. Theoretically,
this is still technically wrong, as the MetaCursorTracker holds onto it.
We'll fix this after we port to logind.
When we move focus elsewhere when unmanaging a window, we *need* to move
the focus, so if the target is globally active, move the focus to the
no-focus-window in anticipation that the focus will normally get moved
to the right window when the target window responds to WM_TAKE_FOCUS.
If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left
on the no-focus-window, but there's no way to distinguish whether the
app will respond or not.
https://bugzilla.gnome.org/show_bug.cgi?id=711618
When we move focus elsewhere when unmanaging a window, we *need* to move
the focus, so if the target is globally active, move the focus to the
no-focus-window in anticipation that the focus will normally get moved
to the right window when the target window responds to WM_TAKE_FOCUS.
If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left
on the no-focus-window, but there's no way to distinguish whether the
app will respond or not.
https://bugzilla.gnome.org/show_bug.cgi?id=711618
When a client spontaneously focuses their window, perhaps in response
to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
Updating display->focus_serial in response to FocusOut then was causing
us to ignore FocusIn and think that the focus was not on any window.
We need to distinguish this spontaneous case from the case where we
set the focus ourselves - when we set the focus ourselves, we're careful
to combine the SetFocus with a property change so that we know definitively
what focus events we have already accounted for.
https://bugzilla.gnome.org/show_bug.cgi?id=720558
When a client spontaneously focuses their window, perhaps in response
to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
Updating display->focus_serial in response to FocusOut then was causing
us to ignore FocusIn and think that the focus was not on any window.
We need to distinguish this spontaneous case from the case where we
set the focus ourselves - when we set the focus ourselves, we're careful
to combine the SetFocus with a property change so that we know definitively
what focus events we have already accounted for.
https://bugzilla.gnome.org/show_bug.cgi?id=720558
Initial placement during meta_window_constrain() can result in changes
to the borders, so we need to recompute our border sizes after
constraining. This fixes incorrect window borders on
initially maximized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=720417
Initial placement during meta_window_constrain() can result in changes
to the borders, so we need to recompute our border sizes after
constraining. This fixes incorrect window borders on
initially maximized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=720417
