When GDK sends an unmaximize _NET_WM_STATE ClientMessage, it tells us to remove
the _NET_WM_STATE_MAXIMIZED_HORZ and _NET_WM_STATE_MAXIMIZED_VERT states. Before
this time, it would independently call:
meta_window_unmaximize (window, META_MAXIMIZE_HORIZONTAL);
meta_window_unmaximize (window, META_MAXIMIZE_VERTICAL);
Which, besides being foolishly inefficient, would also mess up our saved_rect
tracking, causing the window to only look like it was unmaximized vertically.
Make this code more intelligent, so it causes us to unmaximize in one call.
https://bugzilla.gnome.org/show_bug.cgi?id=722108
When GDK sends an unmaximize _NET_WM_STATE ClientMessage, it tells us to remove
the _NET_WM_STATE_MAXIMIZED_HORZ and _NET_WM_STATE_MAXIMIZED_VERT states. Before
this time, it would independently call:
meta_window_unmaximize (window, META_MAXIMIZE_HORIZONTAL);
meta_window_unmaximize (window, META_MAXIMIZE_VERTICAL);
Which, besides being foolishly inefficient, would also mess up our saved_rect
tracking, causing the window to only look like it was unmaximized vertically.
Make this code more intelligent, so it causes us to unmaximize in one call.
https://bugzilla.gnome.org/show_bug.cgi?id=722108
test-path for example uses COGL_ENABLE_EXPERIMENTAL_2_0_API to access
the 2.0 CoglPath api but also uses deprecated framebuffer api such as
cogl_push/pop_framebuffer. Similarly clutter-backend.c builds with
COGL_ENABLE_EXPERIMENTAL_2_0_API and uses cogl_set_framebuffer().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves the framebuffer stack apis out of cogl-framebuffer.c into
cogl/deprecated/cogl-framebuffer-deprecated.c so cogl-framebuffer.c is
more in-line with the master branch to ease cherry picking patches.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves all of the automagic texture constructor prototypes from
cogl-texture.h into a new deprecated/cogl-auto-texture.h file. This also
moves cogl_texture_new_from_sub_texture() into
deprecated/cogl-auto-texture.c
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This makes sure we install a cogl-gst-1.0.pc and
cogl-gst-2.0-experimental.pc file consistent with other sub-libraries
such that cogl-1.x packages can be parallel installed with cogl master.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This makes sure we install a cogl-gles2-1.0.pc and
cogl-gles2-2.0-experimental.pc file consistent with other sub-libraries
such that cogl-1.x packages can be parallel installed with cogl master.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Texture allocation is now consistently handled lazily such that the
internal format can now be controlled using
cogl_texture_set_components() and cogl_texture_set_premultiplied()
before allocating the texture with cogl_texture_allocate(). This means
that the internal_format arguments to texture constructors are now
redundant and since most of the texture constructors now can't ever fail
the error arguments are also redundant. This now means we no longer
use CoglPixelFormat in the public api for describing the internal format
of textures which had been bad solution originally due to how specific
CoglPixelFormat is which is missleading when we don't support such
explicit control over the internal format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 99a53c82e9ab0a1e5ee35941bf83dc334b1fbe87)
Note: there are numerous API changes for functions currently marked
as 'unstable' which we don't think are in use by anyone depending on
a stable 1.x api. Compared to the original patch though this avoids
changing the cogl_texture_rectangle_new_with_size() api which we know
is used by Mutter.
This introduces the internal idea of texture loaders that track the
state for loading and allocating a texture. This defers a lot more work
until the texture is allocated.
There are several intentions to this change:
- provides a means for extending how textures are allocated without
requiring all the parameters to be supplied in a single _texture_new()
function call.
- allow us to remove the internal_format argument from all
_texture_new() apis since using CoglPixelFormat is bad way of
expressing the internal format constraints because it is too specific.
For now the internal_format arguments haven't actually been removed
but this patch does introduce replacement apis for controlling the
internal format:
cogl_texture_set_components() lets you specify what components your
texture needs when it is allocated.
cogl_texture_set_premultiplied() lets you specify whether a texture
data should be interpreted as premultiplied or not.
- Enable us to support asynchronous texture loading + allocation in the
future.
Of note, the _new_from_data() texture constructors all continue to
allocate textures immediately so that existing code doesn't need to be
adapted to manage the lifetime of the data being uploaded.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6a83de9ef4210f380a31f410797447b365a8d02c)
Note: Compared to the original patch, the ->premultipled state for
textures isn't forced to be %TRUE in _cogl_texture_init since that
effectively ignores the users explicitly given internal_format which was
a mistake and on master that change should have been made in the patch
that followed. The gtk-doc comments for cogl_texture_set_premultiplied()
and cogl_texture_set_components() have also been updated in-line with
this fix.
When reading a texture back by first wrapping it as an offscreen
framebuffer and using _read_pixels_into_bitmap() we now make sure the
offscreen framebuffer has an internal format that matches the
meta-texture being read not that of the current sub-texture being
iterated. In the case of atlas textures the subtexture is a shared
texture whose format doesn't reflect the premultipled alpha status of
individual atlas-textures, nor whether the alpha component is valid.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ee425d4f10acd8b008a2c17e5c701fc1d850f59)
CoglPixelFormat is not a good way of describing the internal
format of a texture because it's too specific given that we don't
actually have exact knowledge of the internal format used by the driver.
This makes cogl_texture_get_format private and in the future we'll
provide a better way of querying the channels and their precision.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ffde82981f22bd0185a7f33e1e6e1479f4c295b8)
Note: Since we can't break API compatibility on the 1.x branch this adds
a cogl/deprecated/cogl-texture-deprecated.c file with a
cogl_texture_get_format() wrapper around the private api. This also
moves the cogl_texture_get_rowstride() and cogl_texture_ref/unref()
functions that were previously deprecated into cogl-texture-deprecated.c
This defers checking the internal format and whether accelerated
migration is supported until allocating the texture.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 83b05cbe3969789bc3ec78480c0937a6722efbf1)
Instead of throwing a CoglError exception if an application tries to
allocate a zero size atlas texture this make that a programmer error
instead.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d3eaeedc86d408669b81d6c43ef2b0ab9d859c85)
The plan is to defer a lot more work in creating a texture until
allocation time. This means that for some texture backends we might not
know until after allocation whether the texture is sliced or can support
hardware repeating. This makes sure we trigger an allocation if either
of these are queried.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4868582812dbcd5125495b312d858f751fc31e9d)
The plan is to defer a lot more work in creating a texture until
allocation time. This means we wont be able to assume that all textures
being used to render must have already been allocated when data was
specified.
The latest point at which we will generally require a texture to be
allocated will be when we need to know the underlying GL handle for a
texture and so this updates cogl_texture_get_gl_texture() to ensure the
texture is allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 59f6fefc37524f492512a71b831760a218d9bb95)
The plan is to defer more of the work for creating a texture until
allocation time, but that means we won't be able to always assume
we can query the size of a texture when creating an offscreen
framebuffer from a texture (consider for example using
_texture_new_from_file() where the size isn't known until the file has
been loaded). This defers needing to know the size of the texture
underlying an offscreen framebuffer until calling
cogl_framebuffer_allocate().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9688e7dc1eeae3144729dfd4a4bf409620346bf4)
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
