By keeping all the information in a single map, we avoid multiple
lookups and can switch between frames more easily.
Before ~35us, after ~20us for adding 50 new+old and switching
the frame.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
Using clean struct creation creates a lot of temporary variables in
assembly. Inline the assignments, which generates less code.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
Size and NumRefs are always used together, so consolidate info to
a single table to avoid two separate lookups.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
splitTransform func was creating multiple copies of f32.Affine2D
due to not having access to the internal and passing around non-pointer.
This makes splitTransform from ~8ns to .Split ~2ns.
It seems that the non-pointer receiver was ~0.6ns slower in this case.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
As reported by Chris Waldon, the resize area is big enough to make
it hard or impossible to grab and drag any scroll bars.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit updates the way that we change cursors so that the
hotspot of the cursor is properly set to surface-local coordinates.
The previous raw hotspot coordinates are relative to the cursor
image buffer data, and do not take the buffer's scaling factor
into account.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Previously, we'd scroll so the new viewportStart corresponded to the
clicked position. This felt okay if clicking above the current
indicator, but felt jarring when clicking below it. Centering gives a
consistent behavior regardless of the scroll direction.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
Before, we would set s.dragging to false on pointer.Release and then
immediately set it back to true because we were processing the event and
saw that s.dragging was false.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
Once the user begins dragging, the cursor can move outside the clip
area (or even the window on at least X11), leading to events with
positions that are either negative, or larger than the clip area.
Negative values outright break the delta tracking and cause the
scrollbar to misbehave. Positive values "only" break the invariant of
Scrollbar.ScrollDistance that the returned value is in the range [-1, 1].
Signed-off-by: Dominik Honnef <dominik@honnef.co>
Before this change, Perform and Configure could be called during the
event processing where additional events would be queued. However,
a Maximize animation on macOS works by repeatedly sending draw
requests, and they must not be postponed.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Use binary.LittleEndian directly instead of going through the
binary.Write indirection. This allows the following optimizations to
occur:
- We can reuse our own byte slice between iterations
- We don't have to put g.ID in an interface value
- h doesn't escape
- PutUint32 gets inlined
On top of that, the argument to maphash.Hash.Write doesn't escape, so b
doesn't move to the heap.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
As suggested by Egon Elbre, passing a large struct of function pointers
forces Cgo checks on all of the pointer on every Cgo call. This
change instead passes only the relevant function pointer.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit adds support for the commonly-used XCURSOR_THEME and
XCURSOR_SIZE environment variables. Wayland lacks a protocol-level
way to standardize cursor size right now, but these variables are
used consistently by many applications and compositors. Many users
(including me) will find that their environment is already configuring
these for them, and will get consistent cursor sizing for free.
I explored a lot of ways to tackle this, but it looks like nobody has
ever gotten around to implementing the cursor theme protocol discussed
here:
https://wayland-devel.freedesktop.narkive.com/VuMSOO55/possible-wayland-extension-to-publish-mouse-pointer-size
Given that it doesn't seem to be resolved anytime soon, supporting a
widely-used convention to tweak these things seems reasonable to me.
I say that it fixes issue 382 because it enables the user to make
Gio's cursor size match the rest of their system.
Fixes: https://todo.sr.ht/~eliasnaur/gio/382
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
The app.Window.Perform(ActionMove) is the wrong abstraction for
initiating a move gesture: Windows needs to know the move gesture
area at pointer move, and macOS needs to know the pointer button
down event that triggers the move gesture. This change replaces
Perform(ActionMove) with a new system.ActionInputOp that marks an
area movable.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Allowing clients to initiate resize gestures is a waste: macOS
doesn't support them, and the only reason we added them was to
implement client-side decorations for Wayland. Now all desktop
platforms implement resize gestures as needed, and we no longer
need the system.Action actions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the system.Action machinery for initiating resize
gestures. This is the Wayland implementation that hard-codes the border
drag gesture for resizing.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the client-controlled system.Action machinery
for resize gestures initiated by the client. This is the replacement
implementation for Windows, where the behaviour is hard-coded to
mimic the decorated automatic handling.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As I read the SetWindowPos documentation, SWP_NOZORDER is the correct
flag for keeping the z-order of the window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the WS_OVERLAPPEDWINDOW style for undecorated
windows, in which case the fullscreen assumption will no longer hold.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Not only is the client guaranteed a ConfigEvent, but app.Window
can assume that an unsupported decoration change will be corrected
(by a ConfigEvent with Decorated forced to the supported value).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur