Giu项目窗口异常增长导致崩溃问题分析与修复

问题现象

在Giu项目中，用户报告了一个严重的界面异常问题：当应用程序运行时，窗口会不断自动增长直到填满整个屏幕，最终导致程序崩溃。这个问题在Windows 10系统上尤为明显，特别是在高DPI显示器环境下。

问题重现

通过简单的示例代码即可重现该问题：

package main

import (
	g "github.com/AllenDang/giu"
)

func loop() {
	g.Window("main").Layout(
		g.Labelf("hi"),
	)
}

func main() {
	wnd := g.NewMasterWindow("main", 400, 200, 0)
	wnd.Run(loop)
}

运行上述代码后，可以观察到窗口内容区域会持续扩大，最终触发断言失败导致程序崩溃。

崩溃原因分析

崩溃时的错误信息显示：

panic: Assertion failed!
Expression: g.Style.WindowMinSize.x >= 1.0f && g.Style.WindowMinSize.y >= 1.0f && "Invalid style setting."

深入分析后发现，问题的根源在于DPI缩放处理逻辑存在缺陷。在Windows系统下，Giu会获取系统的DPI缩放比例并应用到界面元素上。然而，当前的实现存在两个关键问题：

1. 缩放操作被放置在渲染循环中，导致每次渲染都会重复应用缩放
2. 缩放操作是累积性的，而非设置绝对值

技术细节

在高DPI显示器（如4K显示器使用150%缩放）环境下，问题尤为明显。代码中原本的处理方式如下：

func (w *MasterWindow) setTheme() (fin func()) {
	// Scale DPI in windows
	if runtime.GOOS == "windows" {
		xScale, _ := Context.backend.ContentScale()
		imgui.CurrentStyle().ScaleAllSizes(xScale)
	}
	// ...
}

这种实现会导致每次渲染循环都会将当前样式再次缩放150%，形成指数级增长的效果。例如：

• 第一次循环：缩放150%
• 第二次循环：在150%基础上再缩放150%（实际225%）
• 第三次循环：在225%基础上再缩放150%（实际337.5%）
• 依此类推...

解决方案

修复方案非常简单但有效：只需确保DPI缩放只执行一次，在窗口初始化阶段完成。修改后的代码如下：

func (w *MasterWindow) setTheme() (fin func()) {
	// Scale DPI in windows
	if runtime.GOOS == "windows" && !w.initialized {
		w.initialized = true
		xScale, _ := Context.backend.ContentScale()
		imgui.CurrentStyle().ScaleAllSizes(xScale)
	}
	// ...
}

通过添加initialized标志位，确保DPI缩放只在首次调用时执行。这样既保留了高DPI显示器的适配能力，又避免了重复缩放导致的问题。

经验总结

这个案例给我们几个重要的启示：

1. DPI缩放处理：在高DPI环境下开发GUI应用时，必须谨慎处理缩放逻辑，确保不会产生累积效应。

2. 初始化与运行时分离：任何只需要执行一次的设置操作（如DPI缩放）都应该明确区分于需要每帧执行的操作。

3. 断言信息的重要性：良好的断言信息能极大帮助开发者快速定位问题根源。

4. 版本回退测试：通过对比不同版本的行为（如v0.7.0工作正常），可以快速缩小问题范围。

该修复已被合并到主分支，并在v0.8.1版本中发布，有效解决了这一影响用户体验的关键问题。