~dominikh

Recent activity

[PATCH gio] app: [X11] implement more correct window lifetimes a month ago

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]

Re: [PATCH gio] internal/ops: reduce inlining complexity of EncodeCommand a month ago

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,

[PATCH gio] internal/ops: reduce inlining complexity of EncodeCommand a month ago

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]

[PATCH gio v2 2/2] gpu: rename resourceCache to textureCache and use concrete key a month ago

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]

[PATCH gio v2 1/2] gpu: remove unused cache parameters a month ago

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]

[PATCH gio 2/2] gpu: rename resourceCache to textureCache and use concrete key a month ago

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]

[PATCH gio 1/2] gpu: remove unused cache parameters a month ago

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]

[PATCH gio 2/2] widget: don't refer to non-existent method Clickable.Clicks a month ago

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]

[PATCH gio 1/2] gesture: adjust ClickKind.String for ClickType -> ClickKind rename a month ago

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]

Fixing the ergonomics of nested scrollable areas 5 months ago

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.