From Dominik Honnef to ~eliasnaur/gio-patches
We cannot assume that our window has been mapped just because we called
XMapWindow. Furthermore, we cannot assume that the window size specified
in XCreateWindow is the size our window has. In both cases, a window
manager can interject and decide to delay mapping us, as well as
configure our window differently. Thus we must wait for a MapNotify
event before switching to the "running" stage. By the time we get the
MapNotify event we'll also have gotten at least one ConfigureNotify
event to tell us about our actual dimensions.
Not doing this correctly caused us to render frames before we knew the
actual window size, which could mess up initial scaling of content done
by applications. And of course we were rendering useless frames, as they
wouldn't be seen.
[message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
Elias Naur <mail@eliasnaur.com> writes: > On Sat, 6 Jan 2024 at 21:14, Dominik Honnef <dominik@honnef.co> wrote: >> >> By avoiding the call to byteslice.Uint32 and doing a direct unsafe cast, >> we can reduce the complexity of EncodeCommand - as seen by the inliner - >> enough to allow op/clip.Path.cmd to be inlined. This removes the call >> overhead and reduces the amount of copying needed to pass in the >> scene.Command. >> > > I'm not keen on adding unsafe (however safe) to fix performance issues. > I believe Egon (CC'ed )at some point suggested changing the underlying ops > representation from []byte to []uint32. It's a much more invasive change,
From Dominik Honnef to ~eliasnaur/gio-patches
By avoiding the call to byteslice.Uint32 and doing a direct unsafe cast,
we can reduce the complexity of EncodeCommand - as seen by the inliner -
enough to allow op/clip.Path.cmd to be inlined. This removes the call
overhead and reduces the amount of copying needed to pass in the
scene.Command.
Since scene.Command is an array, the unsafe cast is no less safe than
the byteslice.Uint32 helper.
In a real application, this reduced the time spent in Path.LineTo (and
children, so including cmd) by 32%.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
---
[message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
The only remaining use of the cache is mapping handles to textures.
Using a concrete type for the key avoids the allocation caused by convT.
If we need more caches again in the future we can copy the type, or make
it generic.
Instead of updating the benchmark, we removed it outright. It suffered
from several flaws:
- The amount of work for each iteration of b.N wasn't constant, because
the same cache was reused, growing ever larger in size.
- It only tested the cost of insertions. The comment "half are the same
and half updated" wasn't true, as calling 'put' with the same key twice
[message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
Signed-off-by: Dominik Honnef <dominik@honnef.co> --- gpu/gpu.go | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gpu/gpu.go b/gpu/gpu.go index fc6511cb..f616fd29 100644 --- a/gpu/gpu.go +++ b/gpu/gpu.go @@ -425,9 +425,9 @@ func (g *gpu) frame(target RenderTarget) error { g.stencilTimer.end() g.coverTimer.begin() g.renderer.uploadImages(g.cache, g.drawOps.imageOps) g.renderer.prepareDrawOps(g.cache, g.drawOps.imageOps) [message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
The only remaining use of the cache is mapping handles to textures. Using a concrete type for the key avoids the allocation caused by convT. If we need more caches again in the future we can copy the type, or make it generic. Signed-off-by: Dominik Honnef <dominik@honnef.co> --- gpu/caches.go | 23 ++++++++++++++--------- gpu/gpu.go | 12 ++++-------- 2 files changed, 18 insertions(+), 17 deletions(-) diff --git a/gpu/caches.go b/gpu/caches.go index b44f7ead..4b88e9d0 100644 [message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
Signed-off-by: Dominik Honnef <dominik@honnef.co> --- gpu/gpu.go | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gpu/gpu.go b/gpu/gpu.go index fc6511cb..f616fd29 100644 --- a/gpu/gpu.go +++ b/gpu/gpu.go @@ -425,9 +425,9 @@ func (g *gpu) frame(target RenderTarget) error { g.stencilTimer.end() g.coverTimer.begin() g.renderer.uploadImages(g.cache, g.drawOps.imageOps) g.renderer.prepareDrawOps(g.cache, g.drawOps.imageOps) [message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
Signed-off-by: Dominik Honnef <dominik@honnef.co> --- widget/button.go | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/widget/button.go b/widget/button.go index 2a335127..e5e06661 100644 --- a/widget/button.go +++ b/widget/button.go @@ -53,8 +53,8 @@ func (b *Clickable) Click() { b.requestClicks++ } // Clicked reports whether there are pending clicks as would be [message trimmed]
From Dominik Honnef to ~eliasnaur/gio-patches
Signed-off-by: Dominik Honnef <dominik@honnef.co> --- gesture/gesture.go | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gesture/gesture.go b/gesture/gesture.go index 14faac45..2676d0bf 100644 --- a/gesture/gesture.go +++ b/gesture/gesture.go @@ -446,13 +446,13 @@ func (a Axis) String() string { func (ct ClickKind) String() string { switch ct { case KindPress: return "TypePress" [message trimmed]
From Dominik Honnef to ~eliasnaur/gio
Using nested scrollable areas, as implemented in Gio (and many other frameworks), leads to the following two bad user experiences when using the scroll wheel: 1. The user starts scrolling the outer area. The inner scrollable area happens to scroll into view and is positioned under the cursor. The inner area now hijacks the scrolling action, and the user can no longer scroll the outer area without moving their cursor to an area unoccupied by the inner area, assuming there is one. 2. The user scrolls the inner area but overshoots one of the ends. This causes the outer area to scroll, which is at best jarring, and at worst pushes the inner area out of view, a "mistake" the user has to correct.