How to close MasterWindow and re-open it again?
What happend?
I'm trying to use giu in conjunction with systray library to make an app that sits in a tray area. The app suppose to have settings window that should be called from tray context menu.
This is where I stuck: I can easily call the giu.NewMasterWindow with it's content like in helloworld example but if I do that multiple times (close window via SetShouldClose method and re-open from tray menu again) the memory consumption started to raise and eventually the window stops drawing elements.
Obviously I'm making a mistake somewhere here - is there any approach where I can destroy MasterWindow on closing and re-create it on menu click from systray? Thanks!
Code example
main.go
package main
// Systray onReady function. Showing part for capturing tray menu click to call giu window
func onReady() {
...
go func() {
for {
select {
case <-mSettings.ClickedCh:
giu.InitSettings()
..
giu.go
package giu
import (
"image/color"
"github.com/AllenDang/giu"
)
// About
var wSettings *giu.MasterWindow
func loop() {
giu.SingleWindow().Layout(
giu.Label("Some settings label"),
giu.Row(
giu.Align(giu.AlignCenter).To(
giu.Button("OK").OnClick(func() {
wSettings.SetShouldClose(true)
}),
),
),
)
}
func InitSettings() {
wSettings = giu.NewMasterWindow("A Title", 380, 270, giu.MasterWindowFlagsNotResizable)
wSettings .Run(loop)
}
To Reproduce
The example shown above is stripped but it shows the main route I went.
Version
v0.5.6 (latest)
OS
windows 10
Just to clarify - it's not a bug so bug label is misleading. Sorry about that.
it may be a bug as well, IMO giu doesn't call some imgui's stuff that cleans its state, and tht's probably because the memory usage rises... (thats only my supposes) u needt to wait for @AllenDang's opinion
@keshon This should be a bug, can you profile it with pprof and check which part leads to the memory raise? I don't have a windows machine by my side...
@AllenDang I tried to profile it but to be honest I did not noticed anything strange (worth to mention I'm no good at profiling). I made an example repo of giu and systray - maybe you can check it if possible?
The thing is that its not possible to see any content in giu window after 3rd or 4th close-open sequence in this example. And private/working sets sizes are started to raise dramatically.
meh @keshon my linux refuses to run your code
[test-giu-systray-app (130) ]$ ./app
2022/02/08 10:14:50 profile: memory profiling enabled (rate 4096), mem.pprof
(app:28482): Gtk-CRITICAL **: 10:14:50.193: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
and no window appears, so sadly, I can't help you
also, it seems to be a problem with them's library - there is an issue for fedora there
meh @keshon my linux refuses to run your code
[test-giu-systray-app (130) ]$ ./app 2022/02/08 10:14:50 profile: memory profiling enabled (rate 4096), mem.pprof (app:28482): Gtk-CRITICAL **: 10:14:50.193: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failedand no window appears, so sadly, I can't help you
also, it seems to be a problem with them's library - there is an issue for fedora there
Could you please try again? I cleaned up go.mod file in the repo to be sure it doesn't contain obsolete requires from my past experiments.
@keshon I meet this issue on my fedora: https://github.com/getlantern/systray/issues/166 And sadly don't have any other os/vm with go-dev enviroument
It's not a systray-related behaviour. Under Windows 10 it's enough to look at memory consumption of this program after each window close:
package main
import (
g "github.com/AllenDang/giu"
)
func main() {
for {
g.NewMasterWindow("Test", 800, 600, 0).Run(func() {})
}
}
I get approx +35 MB each time!
And it's worth to mention, that the memory used by the app is low during the moments when MainWindow is not visible.
Can be seen by adding something like time.Sleep(5 * time.Second) to the for loop above.
Each time new window is shown, the app magically "remembers" previous memory peak and ads 35 MB to it.
Close the window and immediately memory usage drops to 20-30 MB.
UPD: macOS 12.6.1, Go 1.19.3 - 771 MB of memory is used after 10 closes.