giu icon indicating copy to clipboard operation
giu copied to clipboard

How to close MasterWindow and re-open it again?

Open keshon opened this issue 3 years ago • 9 comments

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

keshon avatar Feb 03 '22 11:02 keshon

Just to clarify - it's not a bug so bug label is misleading. Sorry about that.

keshon avatar Feb 03 '22 11:02 keshon

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

gucio321 avatar Feb 03 '22 12:02 gucio321

@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 avatar Feb 03 '22 13:02 AllenDang

@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.

keshon avatar Feb 07 '22 12:02 keshon

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

gucio321 avatar Feb 08 '22 09:02 gucio321

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

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 avatar Feb 08 '22 13:02 keshon

@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

gucio321 avatar Feb 08 '22 13:02 gucio321

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.

jLamer avatar Nov 12 '22 09:11 jLamer