The background image, background image shadow and border image are
allocation-indepedent, so we can keep these in the node. Given that these are
are likely cached in the StTextureCache, the slight increase in code complexity
may not be worth caching these textures and materials -- we might be better off
just computing when we need to paint.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
This ensures that two widgets sharing the same theme node won't trample
on each other's prerendered materials if the actors are of different
sizes. This also tries to be very careful to share as much as possible
during a transition.
This has the side effect that if a widget changes state a bunch of times,
we won't cache every state. Since we expect that state changes are
infrequent and that most cases we'll be able to use the texture cache
to do most of the heavy lifting, this cost is much more insignificant
than rendering a number of different actors with the same theme node
and different sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
Since we now share theme nodes between, we shouldn't cache the paint state
across all nodes. As a first step towards putting this in the actor, split
out the state into another structure. Keep it in the theme node for now
so that we don't make too many changes in one commit.
It's possible that some of these pieces of drawing state could be shared
between theme nodes. For the sake of simplicity, assume that none of them
are shared or should be shared. A future commit could identify those that
could be shared and move them back into the theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
We want to put the paint state in the actor rather than in the theme
node, as having two actors with different sizes but the same theme node
is now much less efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
This simplifies the code required to build remote menus and
put all the items in the right place, and makes us share our
implementation with GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=698427
Similar to the existing generic getter methods, add lookup functions
for URL properties like the standard background-image/border-image
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
The changes from commit b4f5f1e461 and b394d184cc increased the
instructions required for the fade fragment shader. This is over the limit
for some hardware (like intel gen3), which causes the driver to fallback
to software rendering for the shader. The result is that painting a scrollview
that has a fade effect takes around 30 (!!) seconds.
So lets go back to the old effect for 3.8 until we find a solution.
https://bugzilla.gnome.org/show_bug.cgi?id=696404
Previously when a client requests that a window should be docked the
shell would reparent the socket window onto the stage's window and
then use ClutterX11TexturePixmap to get a texture to represent the
window. This will not work if Clutter is no longer using the X11
winsys for example if it becomes its own display server. Instead this
patch leaves the socket window as a child of the root window and lets
mutter create a MetaWindow out of it. If Mutter is acting as a display
server then this mechanism will still work via the headless x server.
The ShellGtkEmbed instance now registers for notification of the
‘window-created’ signal of the display so that it can find the
MetaWindow that gets created to represent the socket window. When this
window is found it is prevented from being displayed on the screen by
setting the actor's opacity to 0. An input shape is then set on the
window to prevent it receiving any input.
Instead of being a subclass of ClutterX11TexturePixmap, ShellGtkEmbed
is now a subclass of ClutterClone. When the MetaWindow is found for
the socket window the clone's source is set to the invisible actor for
the window so it can be displayed in the panel as before.
The ShellEmbeddedWindow no longer needs to know what the stage is
because it no longer reparents the socket window. Therefore the
ShellTrayManager doesn't need to know the stage either so
shell_tray_manager_manage_stage has been replaced with just
shell_tray_manager_manage_screen.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
Pointer tracking is broken when the pointer is over the stage input
area. This is apparently fallout from mutter going to XInput2.
This commit changes the mouse event handling code to also use XInput2.
https://bugzilla.gnome.org/show_bug.cgi?id=695324
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the cut/copy actions for
password entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
Doing so causes useless full stage redraws and breaks culling
as clutter cannot know how the signal handler affects painting.
So use clutter_threads_add_repaint_func_full instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694988
Since commit b4f5f1e461, the effect is eased in at the scroll
view's edges so that it does not appear out of nowhere. However,
the linear easing used is not the best option, as now the effect
appears so late that content near the edges ends up just being
cut off rather than faded out.
So adjust the easing function to have the effect appear faster.
https://bugzilla.gnome.org/show_bug.cgi?id=694327
g_str_has_prefix() will assert when passed NULL, so we need to make
sure that we are passed a non-NULL log_domain first.
Spotted by <goughost<at>yahoo.com.cn>
https://bugzilla.gnome.org/show_bug.cgi?id=663601
If enabled, scrollbars take away from the allocation given to the
view's content. This is usually preferrable to painting the bars on
top of the content, but there are exceptions, for instance when the
content needs to be centered with regard to the view as a whole.
Add a :overlay-scrollbars property to account for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
This commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.
Based on initial work by Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=682429
We cannot reset the cursor at the next leave event, as that might
happen on a NULL stage and cause a BadWindow error, so do it on
unmap (which is guaranteed to happen before the stage is cleared).
https://bugzilla.gnome.org/show_bug.cgi?id=694057
As we use g_slist_prepend for efficiency when building the list
of results before ordering it, we need to make sure we traverse
the list of previous results backwards so that it's built in
the same order.
https://bugzilla.gnome.org/show_bug.cgi?id=693936
GdkPixbuf is stored in memory as individual bytes, in strict red-green-blue-alpha
order, while cairo image surfaces are stored as 32bits units whose
order depends on the endianess.
It is probably possible to do something better, taking advantage
of cogl and the GL using the actual component order, but for now
it is easier to use the GDK utility to convert the cairo surface.
https://bugzilla.gnome.org/show_bug.cgi?id=693931
While we were relying on gtk_icon_info_load_icon and friends being
thread-safe, there was no such guarantee, and recent caching that
was added to GTK+ made it non-threadsafe. To replace it, _async()
variants of the icon loading code were added that are thread-safe.
Use those instead of using our own worker threads.
https://bugzilla.gnome.org/show_bug.cgi?id=692845
Use GdkPixbuf rather then cairo_surface_write_to_png_stream when saving
screenshots because this allows us to embedded metadata into the file which
is used by the background control panel to filter out screenshots.
https://bugzilla.gnome.org/show_bug.cgi?id=693737
