Yes, it's fixed with 0dc99abc5d0e6b253a65f2ad0cca8a06fa96cdc9. :)

I'm working on the implementation of file-dialogs, https://github.com/gioui/gio-x/pull/3, however there's a bug. I can't reproduce this bug on older versions of Gio (such as https://git.sr.ht/~eliasnaur/gio/commit/d51d8b46c3c7f9c695be344e2a9fb681995f74d1). Also, the gowebviewer is facing the of the same issue, which doesn't have before.

---

The bug is:

07-18 21:15:08.402 17913 17939 E libEGL  : eglMakeCurrentImpl:1100 error 3002 (EGL_BAD_ACCESS)
07-18 21:15:08.402 17913 18109 I org.gioui.explorer: eglMakeCurrent error 0x3002
07-18 21:15:08.442  1659  2115 W InputDispatcher: channel '98892b6 org.gioui.explorer/org.gioui.GioActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
07-18 21:15:08.442  1659  2115 E InputDispatcher: channel '98892b6 org.gioui.explorer/org.gioui.GioActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
07-18 21:15:08.442  1659  4003 I WindowManager: WIN DEATH: Window{98892b6 u0 org.gioui.explorer/org.gioui.GioActivity}
07-18 21:15:08.442  1659  4003 W InputDispatcher: Attempted to unregister already unregistered input channel '98892b6 org.gioui.explorer/org.gioui.GioActivity (server)'
07-18 21:15:08.442   955   955 I Zygote  : Process 17913 exited cleanly (1)

There's a full log where (https://paste.sr.ht/~whereswaldon/b21c014691dcfef41e11a276c2f37c0add6ff0e1), with the example to reproduce it. It happens sometimes, so you may need to repeat the process of open the dialog many times (usually three times).

---

The root cause of the bug seems to be related to how Android changes the view/activity (or restart the activity). On older Gio versions, it not happen.

I'm using the Git Bisect trying to find where this bug was introduce, but it's not that easy, since it may ocurr or not.

---

That is the result so far:

Using Git Bisect the bad commit is 13d7a8d7606750b457811f42ba9cd783c01fccc3.

https://git.sr.ht/~eliasnaur/gio/commit/13d7a8d7606750b457811f42ba9cd783c01fccc3

But I'm not 100% sure. Remember that this bug may occur or not, so I try my best to find where the issue comes from. (Also, from 0e592f8bc6b359fcfe7ffbc89df401b601e768f8 to 3fc8f55350da880cf7cd5cc802c37f45f304f0bd the app becomes unresponsive (but not crash). It was fixed, anyway.)

Yes. On the task manager each time that you minimize/maximize it takes ~10MB, and don't get cleared.

My app uses ~30MB, when start. If I minimize/maximize multiple times, it will increase 10MB, so if I minimize ~10 times, it will takes ~140+MB. For some reason the Windows doesn't release those 100MB. :|

-- Lucas Rodrigues inkeliz@inkeliz.com

On Sun, Jul 18, 2021, at 1:25 AM, Lucas Rodrigues wrote:

I'm not sure if manage to reproduce that. On my app there's some allocation when minimize/maximize, but it's removed by the GC.

I'm using the following code to track the memory usage:

func PrintMemUsage() { var m runtime.MemStats runtime.ReadMemStats(&m) // For info on each, see: https://golang.org/pkg/runtime/#MemStats fmt.Printf("Alloc = %v MiB", m.Alloc / 1024 / 1024) fmt.Printf("\tTotalAlloc = %v MiB", m.TotalAlloc / 1024 / 1024) fmt.Printf("\tSys = %v MiB", m.Sys / 1024 / 1024) fmt.Printf("\tNumGC = %v\n", m.NumGC) }

It seems that each minimize/maximize takes 6MB. The GC is triggered, so it will reduce the "alloc". However, the "TotalAlloc" will increase by ~6MB each time:

StageRunning Alloc = 8 MiB TotalAlloc = 15 MiB Sys = 23 MiB NumGC = 9 StagePaused StageRunning Alloc = 14 MiB TotalAlloc = 21 MiB Sys = 27 MiB NumGC = 9 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 27 MiB Sys = 32 MiB NumGC = 10 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 33 MiB Sys = 32 MiB NumGC = 11 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 38 MiB Sys = 32 MiB NumGC = 11 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 44 MiB Sys = 36 MiB NumGC = 12 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 50 MiB Sys = 36 MiB NumGC = 13 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 56 MiB Sys = 36 MiB NumGC = 13 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 62 MiB Sys = 36 MiB NumGC = 14 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 68 MiB Sys = 36 MiB NumGC = 15 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 74 MiB Sys = 36 MiB NumGC = 15 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 80 MiB Sys = 36 MiB NumGC = 16 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 86 MiB Sys = 36 MiB NumGC = 17

On typical use (without mimize/maximize) it doesn't happen. -- Lucas Rodrigues inkeliz@inkeliz.com

On Sat, Jul 17, 2021, at 9:17 PM, ~blankblanket wrote:

It can be seen just by selecting the app from taskbar repeatedly multiple times. About 10MB increases eachtime

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/245#event-91540

Attachments:

• signature.asc

I'm not sure if manage to reproduce that. On my app there's some allocation when minimize/maximize, but it's removed by the GC.

I'm using the following code to track the memory usage:

func PrintMemUsage() { var m runtime.MemStats runtime.ReadMemStats(&m) // For info on each, see: https://golang.org/pkg/runtime/#MemStats fmt.Printf("Alloc = %v MiB", m.Alloc / 1024 / 1024) fmt.Printf("\tTotalAlloc = %v MiB", m.TotalAlloc / 1024 / 1024) fmt.Printf("\tSys = %v MiB", m.Sys / 1024 / 1024) fmt.Printf("\tNumGC = %v\n", m.NumGC) }

It seems that each minimize/maximize takes 6MB. The GC is triggered, so it will reduce the "alloc". However, the "TotalAlloc" will increase by ~6MB each time:

StageRunning Alloc = 8 MiB TotalAlloc = 15 MiB Sys = 23 MiB NumGC = 9 StagePaused StageRunning Alloc = 14 MiB TotalAlloc = 21 MiB Sys = 27 MiB NumGC = 9 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 27 MiB Sys = 32 MiB NumGC = 10 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 33 MiB Sys = 32 MiB NumGC = 11 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 38 MiB Sys = 32 MiB NumGC = 11 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 44 MiB Sys = 36 MiB NumGC = 12 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 50 MiB Sys = 36 MiB NumGC = 13 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 56 MiB Sys = 36 MiB NumGC = 13 StagePaused StageRunning Alloc = 10 MiB TotalAlloc = 62 MiB Sys = 36 MiB NumGC = 14 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 68 MiB Sys = 36 MiB NumGC = 15 StagePaused StageRunning Alloc = 15 MiB TotalAlloc = 74 MiB Sys = 36 MiB NumGC = 15 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 80 MiB Sys = 36 MiB NumGC = 16 StagePaused StageRunning Alloc = 9 MiB TotalAlloc = 86 MiB Sys = 36 MiB NumGC = 17

On typical use (without mimize/maximize) it doesn't happen. -- Lucas Rodrigues inkeliz@inkeliz.com

On Sat, Jul 17, 2021, at 9:17 PM, ~blankblanket wrote:

It can be seen just by selecting the app from taskbar repeatedly multiple times. About 10MB increases eachtime

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/245#event-91540

Attachments:

• signature.asc

Hi,

I could reproduce the issue with Huawei P30, the only physical Huawei that I have. Also, it seems to be a issue with Microsoft SwiftKey, on any device. The characters input is working, delete them is the issue now. However, the original issue is related to Samsung, which seems to be fixed and I can't reproduce the issue on Samsung S21.

I think the issue still related to "prediction"/"suggestions", which SwiftKey is not removing them... If you type "aaa", you need to press "backward/delete" 3 times, then it will start to delete. The amount of clicks needs is exactly the same size of the word that you typed. So, if you enter "abcd" it will take 5 clicks on "backward" to delete "d".

I'm still looking if there's any workaround.

-- Lucas Rodrigues inkeliz@inkeliz.com

On Wed, Jul 14, 2021, at 6:26 AM, ~rexfuzzle wrote:

Hmm, ok, this may not have solved my issue then. On a Huawei it takes a couple of backspace presses before the backspace key starts working. I don't have another phone brand to test it on, but did test it on the tailscale app and the same thing happens. I'm not sure if this is the same problem as the predictions not being available which I raised in ticket #201

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/116#event-90395

Attachments:

• signature.asc

You can use the TYPE_NULL, which is the default one. All types will add InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS | InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD by default.

Those TYPE_TEXT_* is used to disable the text-prediction/grammar-correction (...). I tested that on Samsung S21.

I am a source hut newbie so going to take me time to learn the way of source hut compared to github etc.

You can use the mirror on Github (https://github.com/gioui/gio ). You can also send PR to Github, you just need to sign-off the commit.

Is it not possible to embed the icon after building the exe?

It's possible, but not using go build. Current, the icon is embedded using .syso, which must be placed inside some package.

Some tools like Resource Hacker provides a way to change icon from a compiled exe . So, technically it's possible, but I don't know how that tool works behind the scenes, and we should port it to Golang.

Deleting the .syso seems the best alternative for now. Or find a way to set the syso from outside, using go build.

I'm not sure if component_windows_amd64.syso should follow the -o path. The -o is the executable output, .exe in that case.

However, the .syso is "embedded" by Golang compiler (go build). The only purpose of that is to set the icons and such, but you don't need to distribute it, and it's not required to run the program.

So, in the end: the .syso must live in the package folder to allow the compiler to consume it. The go build will not read that file if we generate the .syso in the output folder

I think we have two options:

1. Delete the .syso after the compile: Create the .syso in the package folder and then delete it.

2. Find a way to specify the .syso from anywhere: IF the go build allow us to determine the .syso from some custom path, we could create the .syso at the output folder (or temporary folder). (~I don't know how or if it's possible~)

On WASM the background is already transparent by default.

I think it's a memory limitation, not a Gio issue. That happens because of the amount of images. The question is: how can I delete those images or replace the content of image?