Commit Graph

8226 Commits

Author SHA1 Message Date
Daniel van Vugt
1f0e4b58ab keyboard: Handle symbolic OSK key codes as explicitly invalid
`key` is an empty string in this case, causing `charCodeAt(0)` to return
`NaN`, which when passed to `Clutter.unicode_to_keysym` now generates an
error in gjs >= 1.67.3:

```
JS ERROR: Error: Argument wc: value is out of range for uint32
```

And the symbolic keys like Backspace, Enter and Caps Lock would have their
presses ignored.

Just skip the call to `charCodeAt` that will fail and allow
`Clutter.unicode_to_keysym` to return its usual error flag.

Fixes: https://bugs.launchpad.net/bugs/1918738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1758>
2021-03-15 12:41:10 +00:00
Daniel van Vugt
c5b18ee66a status/network: Ensure the Cancel button passes undefined to close()
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:

```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```

And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.

Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.

Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
2021-03-15 18:19:04 +08:00
Sebastian Keller
f2db9b52c9 iconGrid: Only use page relative coords for orientation in getDropTarget
The x and y coordinates were both adjusted to be page relative, even
though the icon grid can only scroll in one direction. This was leading
to coordinates outside of the icon grid to be considered part of it and
a wrong drop target to be chosen.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3779

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1767>
2021-03-14 18:44:03 +00:00
Florian Müllner
3c221cea48 overview: Fix showApps() compatibility method
The method is unused in gnome-shell itself, but extensions may still
want to call it, so make sure it actually works.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3873

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1766>
2021-03-14 12:47:42 +00:00
Florian Müllner
d271a51bfd swipeTracker: Remove unused property
The :allow-long-swipes GObject property relies on the automatic
getter/setter added by gjs and is not actually backed by
_allowLongSwipes.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1765>
2021-03-13 22:32:23 +00:00
Jonas Dreßler
d49606bbaa overview: Get rid of panel ghost actor
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.

We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.

This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
ae23ad372d overviewControls: Return zero preferred size
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.

Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
9152d6613b workspacesView: Store some variables outside the children-allocate loop
We've seen this to help quite a bit with performance previously, so also
do it here.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
c239cd398d overviewControls: Hide the appDisplay when it's not shown
Hiding actors allows excluding them from layout, so by hidding the
appDisplay in all the cases where the overviewAdjustment is not actually
showing it, we can save a lot of time on the first frame of painting
the overview because we no longer have to layout the whole appGrid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
d21a0b186e iconGrid: Subclass a C actor for BaseIcon
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
36b103525c keyboard: Correctly compare cursor rect to keyboard rect
The logic that decides whether we should shift the window up when the
cursor rectangle overlaps with the keyboard rectangle doesn't work
properly right now, we want it to work like this:

- If the currently focused window is shifted up, keep it shifted up
until the cursor rect no longer overlaps the keyboard rect. To do that
comparison correctly, we need to adjust for the height the cursor rect
is shifted up by (keyboardHeight) and temporarily shift it down again.

- If the currently focused is not shifted up, we want to shift it up as
soon as the focus rect overlaps the keyboard rect. If that's not the
case, want still want to call _setFocusWindow(null) in order to shift
the previously focused window back down.

This fixes two issues: 1) We're currently shifting windows back down at
the wrong position of the cursor (that is y < keyboardHeight). 2) We're
not shifting down previously focused windows when focusing a different
window with the new focus in a specific region (y >= keyboardHeight &&
y + h < monitor.y + monitor.height - keyboardHeight).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
95ed7c7a06 keyboard: Add proper tracking of window movements to focus tracker
So far the FocusTracker of the OSK can only recognize grab ops on a
window, that is when the user grabs the window using a mouse or the
touchscreen and actively drags it somewhere.

Window can also be moved using keyboard shortcuts, fullscreen buttons or
other ways which don't rely on grabs. Start also supporting those window
movements by listening to the "position-changed" signal on the currently
focused window and emitting the new "window-moved" signal in that case.

Because the OSK sometimes moves windows by itself, we temporarily
disconnect from that new signal while we move the focused window in
_windowSlideAnimationComplete().

This also takes care of resetting this._focusWindowStartY on movements
of the window.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
7b990daee2 keyboard: Animate focus window using position instead of translation-y
Commit 8526776b4a changed the OSK to use
the translation-y property of the MetaWindowActor when animating a focus
window, which broke two things:

1) It's not compatible with the obscured region culling we do for
windows in mutter. That's because MetaCullable strictly operates in
integer coordinates and thus has to ignore any transformations
(translation-y is a transformation). Because of this, during the
animation and gesture, window damage is now tracked incorrectly,
introducing painting issues. The best fix for this would probably be
factoring in transformations when tracking damage in MetaCullable, but
that's not feasible right now.

2) It broke the shifting up of maximized and tiled windows, likely that
is because they are positioned using constraints internally, and mutter
enforces those constraints every time meta_window_move_frame() is
called, not allowing the window to move somewhere else.

To fix both issues, go back to the old way of shifting the window for
now, using the fixed y position of the ClutterActor. To make sure the
drag-up gesture still works, store the initial y1 position of the window
and then use that as a reference point for all our animations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
2cf8b93a7b keyboard: Allow closing immediately
Just like opening the OSK, make it possible to close it immediately,
we'll make use of this in the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
95b83575cb keyboard: Don't move focusWindow back down on window grab
I suggested it myself when reviewing
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668, so
here I am reverting that again...

The difference between calling _setFocusWindow(null) and simply
unsetting the focusWindow is that the former animates the window back to
its position before we shifted it up, while the latter simply "lets go
of the window".

In this case we actually want the latter because after the user grabbed
the window, we obviously should not animate it away right underneath the
users pointer/finger.

To ensure the same mistake doesn't happen again, add a small comment
explaining why this code is as it is.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Alexander Mikhaylenko
f48e58a81a swipeTracker: Reset before emitting 'end' and not after
If the actor is unmapped in the handler, the touch gesture will cancel.
Since we haven't reset the state yet, it will still work and will actually
cancel the gesture, so reset before that instead.

Fixes overview cancelling when trying to open it with a swipe.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
3c1074085e swipeTracker: Clamp position when long swipes are enabled too
Avoid wrapping back to the first page when swiping forward from the last
page.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
df4c05f834 swipeTracker: Pass orientation in constructor
When this class was written, all swipes in the shell were vertical, so it
made sense to make the default orientation vertical. This isn't the case
anymore, thus pass make it mandatory to specify orientation when creating
a tracker.

Change the property default values to horizontal as well to match Clutter
instead of the old shell design.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
c06bc74d6d swipeTracker: Check orientation with a threshold for touchpad
Avoid picking the direction too early.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3755

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Jonas Dreßler
b160e44dab keyboard: Stop offsetting the focus rectangle
The focus rectangle of the OSK currently gets stored with an offset that
removes the global coordinates and makes it window-local coordinates.
This offsetting has been applied since the introduction of the
FocusTracker with commit fc5ab44704 and it
seems there's no real reason for it.

By removing this, we also emit position-changed when the window has
moved but the window-local coordinates stayed the same. We really want
to emit position-changed in that case because it might affect whether
the window needs to be shifted up.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
746230f8b6 keyboard: Ignore focus rects outside the window
Apparently some clients, including gtk don't "clip" the focus rectangle
to their window bounds when scrolling the focus outside the window. This
makes us shift up windows when the focus actually is no longer visible.

This issue needs fixing in GTK, it should probably stop reporting
focus changes when the focus moves outside of the visible view. We can
still do a little bit better on our side though and "clip" the rectangle
to the windows frame rect: If it moves out of the window, we simply stop
updating our focus rect.

The intersection check introduces a small problem though: Some clients
(for example gedit) will give us a cursor rect that has a 0 width or
height. This won't play well with graphene_rect_intersect()
(GrapheneRects never intersect if they are 0-sized), so we set the size
to 1 in case we get a 0-sized rectangle.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
7c83cbe135 keyboard: Use GrapheneRect in focus tracker
This will be useful in the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
3acf840c99 keyboard: Initialize the FocusTrackers current window correctly
The FocusTracker keeps track of the currently focused window using its
internal this._currentWindow property. It will only pick up the focused
window though when receiving a "notify::focus-window" signal, so the
focused window that's set when the FocusTracker is created won't be
picked up.

Fix that by setting the _currentWindow during creation of the
FocusTracker.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
d8adeba6b6 keyboard: Properly destroy focus manager when destroying keyboard
We're currently leaking this object, so make sure to disconnect
everything properly and plug the leak.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
6f39d76a3e keyboard: Remove unused argument
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
9f415f1c89 keyboard: Make a few functions private
Now that we got rid of the external calls to setCursorLocation(), we can
make that private. animateShow() and animateHide() weren't called from
outside anyway, so let's make those private, too.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
f3f0396b7e keyboard: Clear keyboard rest timer when opening immediately
When immediate is true on open(), we want to show the OSK immediately,
it also makes sense to cleanup the keyboard rest timer in that case.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
cb68bbee36 keyboard: Rename focusTracker "reset" signal to "window-grabbed"
What this signal does is fire when a window was grabbed. A receiver
might want to do something special when a window was grabbed, whereas
"reset" can mean anything. Rename the "reset" signal to
"window-grabbed".

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Florian Müllner
16c7739170 messageTray: Remove deprecated code
Originally the Source method for showing notifications was "notify",
which had to change when turning it into a GObject subclass to not
clash with g_object_notify().

That change happened during the 3.36 cycle, so extensions have had
two releases (a year) to adapt to the replacement. That seems long
enough, so remove the deprecated compat code.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3848

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1749>
2021-03-10 15:17:52 +00:00
Jonas Dreßler
59b97a3095 workspace: Use Util.lerp() instead of actor box for interpolating
Instead of interpolating our workspace and layout boxes for each child
using clutter_actor_box_interpolate(), use our Util.lerp() function and
stay in JS land instead.

This is quite a large performance improvement since it avoids
heap-allocating a new ClutterActorBox for every child. With this, we're
finally at a duration of 1.0 ms to allocate the Workspace with 20
windows.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
afb56df55c windowPreview: Subclass a C actor
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.

This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
650e0960a2 workspace: Get some values outside the children loop when allocating
It turned out that getting properties and saving them to a variable
outside of loops instead of accessing them everytime inside the loop can
have significant impact on performance, so do that in Workspaces
vfunc_allocate().

Here the impact is not that large, about 0.05 ms with 20 open windows,
that still seems worth it though.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
5792b98f79 workspace: Don't create useless childBox
Creating a ClutterActorBox here is superfluous, we actually create and
assign a new box to this variable inside the loop.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
ec4b9b8894 workspace: Don't do checks in animateAllocation()
These checks aren't needed since Clutter should enforce this for us
already and skip the implicit transition when possible. This gets our
time spent in vfunc_allocate() down to 2.0 ms with 20 windows

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
3e9a08a2e1 workspace: Use set_origin/set_size instead of properties when allocating
Setting four properties is more expensive than calling two C functions,
so move to set_origin()/set_size() calls for our ClutterActorBox
handling.

This gets us down to an average time of 2.1 ms spent in vfunc_allocate()
with 20 windows

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
e75f3a8aed workspace: Iterate windowSlots directly when allocating
We can save a little bit of time in this loop by iterating directly
over the windowSlots array instead of iterating through children and
then performing a search for the windowSlot. This saves more time and we
only spend 2.2 ms instead of 2.3 ms in vfunc_allocate() now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
04c781674c Move WindowPreviewLayout from JS to C
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.

We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.

In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
5de9166f7a panel: Only update appMenu icon when the app actually changed
Right now we always recreate the icon of the appMenu when calling
_sync(). This will relayout the panel everytime we open the overview,
because we call _sync() in that case.

We can easily avoid that by only recreating the icon actor in case the
app that's opened actually changes. This gets us close to doing no more
relayouts of the panel when opening the overview.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
2021-03-09 13:15:09 +00:00
Jonas Dreßler
e6c1db2bc8 panel: Don't completely hide AppMenuButton when invisible
We already set the AppMenuButton to be non-reactive and transparent when
we hide it. Hiding it completely using clutter_actor_hide() will
additionally make it no longer affect layout and thus queue a relayout.

Since we hide the appMenu in the overview and we want to avoid
relayouting the panel when entering and leaving the overview, don't
completely hide the AppMenuButton to avoid queueing this relayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
2021-03-09 13:15:09 +00:00
Florian Müllner
fb1ab4f20b windowManager: Limit super-scroll handling to normal mode
The overview has it's own workspace scroll handling, and we don't want
to switch workspaces in other modes. Limiting the scroll-event handler
to NORMAL mode matches the swipe tracker used by WorkspaceAnimation,
and allows for other uses of scroll events (like scrolling in the
alt-tab popup).

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3840

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1746>
2021-03-09 12:28:36 +00:00
Sebastian Keller
b853316498 ctrlAltTab: Fix usage of bind_cairo_surface_property
This updates the use of bind_cairo_surface_property for the changes
from d7cb2eeebc. Now this function returns a StImageContent and not
an Actor like the following code expects, so wrap it in a StIcon.
Also the function lost its size argument.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
2021-03-08 09:21:25 +00:00
Jonas Dreßler
7a57528bd7 workspaceThumbnail: Update visibility when showing the overview
There's currently a bug that we continue showing the workspace minimap
when the number of workspaces changes back to 1 during the session (ie.
outside the overview). Fix that by also updating the workspaceThumbnails
visibility when entering the overview.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1741>
2021-03-04 12:39:37 +00:00
Ivan Molodetskikh
35fb221a7e workspace: Check if index is valid before using it
If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547

I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1727>
2021-03-03 19:56:45 +00:00
Florian Müllner
30f0c9f943 workspaceThumbnails: Update indicator on workspace changes
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.

To fix that, update the indicator on workspace changes as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Florian Müllner
fac50fb50e workspaceThumbnail: Queue state update after expanding
New workspaces are added in two steps, first the minimap expands to make
room for the new thumbnail, then the thumbnail animates in. However we
currently don't queue a state update after the first step, so the second
one only happens after one is queued by some other event (like a workspace
switch).

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3748

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Jonas Dreßler
7f99655067 iconGrid: Only animate items when we actually need it
Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.

This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:16 +00:00
Jonas Dreßler
7771bf4437 iconGrid: Save class variables to local ones
It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.

This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:16 +00:00
Jonas Dreßler
7a5650d868 iconGrid: Bail out of getRowPadding early if we'll return 0
This gets our time spent in vfunc_allocate() down again by ~0.1 ms from
1.4 ms to 1.3 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
0fd394d4ca iconGrid: Don't update pages in vfunc_allocate()
vfunc_allocate() is a hot path, and we don't want to do expensive stuff
there, so avoid updating the pages, which seems unnecessary anyway.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
0978b87e65 iconGrid: Get max child size using existing array of visible children
Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.

Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00