当前位置：首页 > news >正文

嵌入式GUI开发实战：emWin窗口管理器消息机制、ToolTips与多图层应用详解

news 2026/6/20 12:59:59

1. 项目概述：为什么窗口管理器是嵌入式GUI的“中枢神经”

在嵌入式系统里做图形界面开发，和你在PC上写个桌面应用完全是两码事。资源受限、实时性要求高、硬件五花八门，这些限制决定了你不能简单地把Windows或Linux那套窗口系统搬过来。这时候，一个高效、可靠的窗口管理器（Window Manager, WM）就成了整个GUI系统的“中枢神经”。它不光是画几个框框那么简单，而是负责协调屏幕上所有“活动部件”——窗口、控件、图层——如何有序地创建、显示、交互和销毁。

emWin作为一款在嵌入式领域广泛应用的GUI库，其窗口管理器正是基于经典的消息驱动架构。你可以把它想象成一个高效的“消息分发中心”。用户按下一个按钮（产生WM_TOUCH消息），系统需要刷新某个区域（产生WM_PAINT消息），或者一个定时器到期了（产生WM_TIMER消息）……所有这些事件都被封装成消息，由窗口管理器精准地投递到对应的窗口回调函数里。你的应用程序逻辑，就写在这些回调函数中对不同消息的响应里。这种机制的好处是解耦：绘制归绘制，逻辑归逻辑，输入处理归输入处理，代码结构清晰，维护起来也方便。

但在实际项目中，光理解基本消息循环是远远不够的。我遇到过不少工程师，界面跑起来看似没问题，一上复杂功能就各种“灵异事件”：ToolTips乱闪、图层叠加后触摸错乱、半透明效果变成一团黑……这些问题追根溯源，往往是对窗口管理器的几个高级特性和使用约束理解不透。本文将结合我踩过的坑和项目经验，深入剖析emWin窗口管理器的三个核心实战难点：消息机制的细节与陷阱、ToolTips功能的实现与定制，以及多图层（Multi-Layer）应用下的协同工作原则。目标是让你不仅会用API，更能理解其背后的设计逻辑，写出稳定、高效的嵌入式GUI代码。

2. 消息机制深度解析：从数据流到避坑指南

消息机制是窗口管理器的基石。很多人觉得处理WM_PAINT和WM_TOUCH就够了，但要想处理复杂交互和优化性能，必须深入到消息流转的细节中去。

2.1 消息的生命周期与数据结构

每一个发送给窗口的消息，都是一个WM_MESSAGE结构体。这个结构体就像快递包裹，里面包含了“发件人”、“收件人”、“消息类型”和“货物内容”。

typedef struct { WM_HWIN hWin; // 接收消息的窗口句柄（收件人地址） int MsgId; // 消息ID（包裹类型，如WM_PAINT, WM_TOUCH） WM_HWIN hWinSrc; // 触发消息的源窗口句柄（发件人地址，常用于通知消息） union { const void* p; // 指向附加数据结构的指针（比如指向GUI_RECT, GUI_PID_STATE） int v; // 直接传递一个整型值 } Data; // 消息负载（货物内容） } WM_MESSAGE;

关键理解：Data这个联合体（union）的使用是消息处理的关键。当MsgId是WM_PAINT时，Data.p指向一个GUI_RECT，告诉你哪个区域脏了需要重画。当MsgId是WM_GET_ID时，你需要把窗口ID写入Data.v。用错了类型，轻则功能异常，重则内存访问错误导致系统崩溃。

2.2 核心系统消息处理实战

手册里列出了几十种消息，但最常用、也最容易出问题的就下面这几个。我们结合代码看具体怎么处理。

2.2.1 WM_PAINT：绘制的唯一入口与性能关键

这是最重要的消息，没有之一。黄金法则：所有屏幕绘制操作，必须在WM_PAINT消息处理中进行。即使你在别的逻辑里算好了要画什么，也得先标记区域为无效（Invalidate），等待WM发送WM_PAINT消息过来再画。

static void _cbWindow(WM_MESSAGE *pMsg) { switch (pMsg->MsgId) { case WM_PAINT: { // 1. 获取需要重绘的区域（脏矩形） const GUI_RECT *pRect = (const GUI_RECT *)pMsg->Data.p; // 2. 开始绘制 GUI_SetBkColor(GUI_BLUE); GUI_SetColor(GUI_WHITE); GUI_ClearRect(pRect->x0, pRect->y0, pRect->x1, pRect->y1); // 只清除脏区域，提升性能 // 3. 你的绘制逻辑 GUI_DispStringAt("Hello World", pRect->x0, pRect->y0); // 注意：如果窗口有透明部分，可能需要特殊处理 if (_IsWindowTransparent) { GUI_EnableAlpha(1); // ... 透明绘制 GUI_EnableAlpha(0); } break; } // ... 处理其他消息 } }

避坑指南：

性能陷阱：不要在WM_PAINT里做耗时计算（如复杂解析、大内存拷贝）。应该在其他消息或后台任务中准备好数据，WM_PAINT只负责快速绘制。
脏矩形利用：Data.p提供的脏矩形是你的朋友。只重绘这个矩形内的内容，能极大提升绘制效率，尤其在低性能MCU上。不要总是GUI_Clear()整个窗口。
透明绘制顺序：如果窗口有透明效果，确保在WM_PAINT中正确启用和禁用Alpha混合，并且绘制顺序符合预期（通常从背景往前景画）。

2.2.2 WM_TOUCH 与 WM_PID_STATE_CHANGED：触摸事件的精细处理

触摸和鼠标输入是交互的核心。emWin通过WM_TOUCH和WM_PID_STATE_CHANGED两个消息来传递状态。

case WM_TOUCH: { const GUI_PID_STATE *pState = (const GUI_PID_STATE *)pMsg->Data.p; if (pState == NULL) { // 手指/鼠标在按下状态时移出了屏幕边界 _HandleTouchReleaseOutside(); break; } int x = pState->x; int y = pState->y; int Pressed = pState->Pressed; if (Pressed) { // 按下事件：可能开始拖拽、激活按钮等 _HandleTouchDown(x, y); } else { // 释放事件：可能触发点击动作 _HandleTouchUp(x, y); } break; } case WM_PID_STATE_CHANGED: { const WM_PID_STATE_CHANGED_INFO *pInfo = (const WM_PID_STATE_CHANGED_INFO *)pMsg->Data.p; // pInfo->State 是当前状态 (1按下, 0释放) // pInfo->StatePrev 是之前的状态 // 这个消息在 WM_TOUCH 之前发送，适合做状态切换的预处理 if (pInfo->State && !pInfo->StatePrev) { // 刚刚按下，可以在这里设置一些按下态标志 _SetPressedFlag(1); } break; }

重要区别与联动：

WM_PID_STATE_CHANGED：仅在按下/释放的瞬间发送一次，告诉你状态变了。Data.p指向WM_PID_STATE_CHANGED_INFO。
WM_TOUCH：在按下、移动（保持按下）、释放时都会发送，传递连续的坐标信息。Data.p指向GUI_PID_STATE。
典型流程：手指按下 ->WM_PID_STATE_CHANGED(State:1) ->WM_TOUCH(Pressed:1) -> 手指移动 ->WM_TOUCH(Pressed:1) ... -> 手指抬起 ->WM_PID_STATE_CHANGED(State:0) ->WM_TOUCH(Pressed:0)。

避坑指南：

不要混淆数据结构：两个消息的Data.p指向不同结构体，直接强制转换会出错。
处理pState == NULL：在拖拽操作中，如果手指快速划出屏幕，WM_TOUCH的Data.p可能为NULL，你的代码必须能优雅处理这种情况，避免空指针访问。
WM_CF_UNTOUCHABLE标志：如果一个窗口（比如仅用于显示的背景图）不需要触摸，创建时加上WM_CF_UNTOUCHABLE标志。触摸事件会直接传递给它的父窗口，可以减少不必要的消息传递，提升响应速度。

2.2.3 WM_TIMER：简易定时任务调度

在GUI中，动画、闪烁、延时显示都离不开定时器。WM_CreateTimer()创建的定时器超时后，会向指定窗口发送WM_TIMER消息。

// 创建定时器，1000ms后触发，窗口句柄为hWin，定时器ID为TIMER_ID_ANIM WM_HTIMER hTimer = WM_CreateTimer(hWin, TIMER_ID_ANIM, 1000, 0); // 在窗口回调中处理 case WM_TIMER: { int TimerId = pMsg->Data.v; // 获取是哪个定时器到期了 switch (TimerId) { case TIMER_ID_ANIM: _UpdateAnimationFrame(); // 更新动画帧 WM_InvalidateWindow(hWin); // 标记窗口无效，触发重绘 WM_RestartTimer(hTimer, 100); // 每100ms重启一次，实现连续动画 break; case TIMER_ID_BLINK: _ToggleBlinkState(); WM_InvalidateWindow(hWin); break; } break; } // 不再需要时删除 WM_DeleteTimer(hTimer);

避坑指南：

及时删除：定时器是系统资源，如果窗口被删除，务必用WM_DeleteTimer()删除其关联的定时器，否则会导致内存泄漏和无效消息。
避免阻塞：WM_TIMER处理函数必须非常快。如果定时任务很耗时，应该只是设置一个标志位，让主循环或其他任务去处理实际工作。
精度问题：emWin的定时器依赖于你调用GUI_Delay()或WM_Exec()的频率。它不是一个高精度硬件定时器，不适合做精确定时控制。

2.2.4 用户自定义消息：模块间通信的桥梁

当你的界面复杂到有多个自定义控件或窗口需要通信时，系统消息就不够用了。这时需要自定义消息。

// 1. 定义自己的消息ID，从WM_USER开始递增 #define MSG_DATA_READY (WM_USER + 0) #define MSG_CONFIG_CHANGE (WM_USER + 1) #define MSG_CUSTOM_DRAW (WM_USER + 2) // 2. 在发送方窗口发送消息 WM_MESSAGE Msg; Msg.MsgId = MSG_DATA_READY; Msg.Data.p = (void*)&sensorData; // 可以附带数据指针 WM_SendMessage(hTargetWin, &Msg); // 3. 在接收方窗口处理消息 case MSG_DATA_READY: { SensorData_t *pData = (SensorData_t *)pMsg->Data.p; _UpdateDisplayWithData(pData); break; }

避坑指南：

数据生命周期：如果你通过Data.p传递了一个指向局部变量的指针，必须确保接收方在处理消息时，该变量仍然有效。通常传递全局变量、静态变量或动态分配的内存（并约定好释放责任）。
消息泛滥：避免在高频循环（如1ms定时器）中发送大量自定义消息，会淹没消息队列。考虑合并消息或使用标志位轮询。

3. ToolTips实现详解：从创建到高级定制

ToolTips（工具提示）那个鼠标悬停时出现的小文字框，对于提升用户体验至关重要。emWin内置了ToolTips支持，但用得好需要一些技巧。

3.1 ToolTips的工作原理与配置

ToolTips的行为由几个时间参数控制：

PERIOD_FIRST：指针首次悬停在控件上，到ToolTip出现的时间。
PERIOD_SHOW：ToolTip出现后，如果指针保持不动，ToolTip持续显示的时间。
PERIOD_NEXT：指针在同一个父窗口内，从一个工具移到另一个工具时，ToolTip出现的延迟时间（通常很短）。

这些参数可以通过WM_TOOLTIP_SetDefaultPeriod()在运行时全局配置。理解这个状态机，才能调试为什么有时ToolTip不出现或消失得太快。

3.2 两种创建方式与实战代码

根据你的控件是否有ID，创建方式分为两种。

3.2.1 为对话框项创建（控件有ID）

这是最常见和简单的方式，适用于通过GUI Builder或DIALOG.h创建的按钮、文本等控件。

#include "DIALOG.h" #include "WM.h" #define ID_BUTTON_INFO (GUI_ID_USER + 0x10) #define ID_SLIDER_VOLUME (GUI_ID_USER + 0x11) // 对话框资源列表 static const GUI_WIDGET_CREATE_INFO _aDialogCreate[] = { { FRAMEWIN_CreateIndirect, "Settings", 0, 0, 0, 320, 240, 0, 0, 0 }, { BUTTON_CreateIndirect, "Help", ID_BUTTON_INFO, 10, 10, 80, 30, 0, 0, 0 }, { SLIDER_CreateIndirect, NULL, ID_SLIDER_VOLUME, 10, 50, 200, 30, 0, 0, 0 }, }; // ToolTip信息数组：{控件ID, 提示文本} static const TOOLTIP_INFO _aTooltipInfo[] = { { ID_BUTTON_INFO, "Click to get contextual help" }, { ID_SLIDER_VOLUME, "Adjust system volume (0-100)" }, }; void CreateSettingsDialog(void) { WM_HWIN hDialog; WM_TOOLTIP_HANDLE hToolTip; // 创建对话框 hDialog = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0); // 创建ToolTip对象，并关联信息数组 hToolTip = WM_TOOLTIP_Create(hDialog, // 父窗口（对话框本身） _aTooltipInfo, // ToolTip信息数组 GUI_COUNTOF(_aTooltipInfo)); // 数组元素个数 // 可选：自定义ToolTip外观 WM_TOOLTIP_SetDefaultFont(&GUI_Font16_ASCII); WM_TOOLTIP_SetDefaultColor(GUI_GRAY, GUI_WHITE, GUI_BLUE); // 文本色，背景色，边框色 // 如果后续动态添加控件，也可以用 WM_TOOLTIP_AddTool // WM_HWIN hNewBtn = BUTTON_CreateEx(...); // WM_TOOLTIP_AddTool(hToolTip, hNewBtn, "New Button Tip"); }

关键点：WM_TOOLTIP_Create的第一个参数是父窗口句柄，ToolTip会监控这个父窗口下的所有指定子控件。TOOLTIP_INFO数组建立了控件ID到提示文本的映射。

3.2.2 为普通窗口创建（控件无ID）

如果你是用WM_CreateWindow手动创建的自定义窗口，它们通常没有ID，就需要换一种方式。

static void _cbToolWindow(WM_MESSAGE *pMsg) { // 一个简单的工具窗口，只绘制一个色块 switch (pMsg->MsgId) { case WM_PAINT: GUI_SetBkColor(GUI_RED); GUI_Clear(); GUI_DispStringHCenterAt("Tool", 50, 15); break; default: WM_DefaultProc(pMsg); // 重要！处理其他默认消息 } } void MainTask(void) { GUI_Init(); WM_SetDesktopColor(GUI_BLACK); // 创建父窗口 WM_HWIN hParent = WM_CreateWindow(10, 10, 200, 150, WM_CF_SHOW, _cbParentWindow, 0); // 创建一个作为“工具”的子窗口 WM_HWIN hTool = WM_CreateWindowAsChild(20, 20, 100, 50, hParent, WM_CF_SHOW, _cbToolWindow, 0); // 创建ToolTip对象，初始化为空 WM_TOOLTIP_HANDLE hToolTip = WM_TOOLTIP_Create(hParent, NULL, 0); // 通过窗口句柄直接添加工具 WM_TOOLTIP_AddTool(hToolTip, hTool, "This is a custom tool window"); while(1) { GUI_Delay(100); } }

关键点：

WM_TOOLTIP_Create的第二个参数传NULL，第三个参数传0。
使用WM_TOOLTIP_AddTool，传入ToolTip对象句柄、工具窗口的句柄（hTool）和提示文本。
务必在自定义窗口回调中调用WM_DefaultProc(pMsg)，否则窗口无法正常处理基础消息（如绘制、尺寸变化），会导致ToolTip依赖的底层机制失效。

3.3 常见问题与高级技巧

ToolTip不显示：
- 检查父窗口：确保WM_TOOLTIP_Create传入的父窗口句柄正确，且该窗口是工具窗口的直系父窗口或祖父窗口。
- 检查窗口可见性与使能：工具窗口本身必须是可见的（WM_CF_SHOW）且未被禁用（WM_DisableWindow）。
- 检查消息循环：确保主循环在持续调用GUI_Delay()或WM_Exec()，否则消息得不到处理。
ToolTip样式定制：除了设置字体颜色，emWin的ToolTip本身也是一个窗口。你可以通过WM_GetCallback获取其回调函数句柄，然后WM_SetCallback替换成你自己的回调，在WM_PAINT中完全自定义绘制，实现圆角、阴影、图片等效果。
动态更新提示文本：WM_TOOLTIP_AddTool后，emWin内部保存了文本的拷贝。如果你想动态改变文本，需要先WM_TOOLTIP_Delete旧的，再重新创建和添加。或者，更高级的做法是继承ToolTip窗口类，在自己的回调函数中根据某个标识动态生成文本。
性能考虑：在资源非常紧张的系统中，ToolTip的持续计时和显示会带来一些开销。如果不需要，可以在发布版本中通过宏定义关闭相关代码。

4. 多图层应用实战：硬件加速下的协同与陷阱

现代嵌入式显示控制器（如STM32的LTDC，NXP的PXP）大多支持多层（Layer）叠加，这能实现炫酷的UI效果（如视频层、半透明菜单、静态背景层）。但多图层也带来了管理的复杂性，emWin窗口管理器在这里扮演着“交通警察”的角色。

4.1 核心原则：图层隔离与WM_PAINT至上

原则一：一个窗口的所有绘制，必须在其所属图层的WM_PAINT消息内完成。

这是最容易犯错的地方。看到GUI_SelectLayer()这个API，可能会想：“我直接切到图层2画个东西不行吗？”不行！绝对不要在WM_PAINT外部，或在一个窗口的WM_PAINT内部去绘制另一个图层的内容。

// 错误示范！这将导致不可预知的行为：闪烁、残影、触摸错乱。 static void _cbLayer1Window(WM_MESSAGE *pMsg) { switch (pMsg->MsgId) { case WM_PAINT: // 在图层1的窗口里绘制图层1的内容 GUI_SetLayer(0); GUI_Clear(); // ... 然后突然去画图层2 GUI_SetLayer(1); // 危险操作！ GUI_DrawBitmap(&bmOverlay, 0, 0); break; } } // 正确做法：每个图层有自己独立的窗口树，绘制互不干扰。 static void _cbLayer0Window(WM_MESSAGE *pMsg) { switch (pMsg->MsgId) { case WM_PAINT: GUI_SetBkColor(GUI_BLUE); GUI_Clear(); // 只清理和绘制图层0 break; } } static void _cbLayer1Window(WM_MESSAGE *pMsg) { switch (pMsg->MsgId) { case WM_PAINT: // 这个窗口创建在图层1上，它的WM_PAINT自然在图层1的上下文中执行 GUI_DrawBitmap(&bmOverlay, 0, 0); // 绘制图层1的内容 break; } } void MainTask(void) { GUI_Init(); // 初始化多个图层... GUI_SelectLayer(0); WM_CreateWindow(...); // 创建属于图层0的窗口 GUI_SelectLayer(1); WM_CreateWindow(...); // 创建属于图层1的窗口 // 后续操作通过WM消息驱动，不要手动切换图层 }

为什么必须这样？因为窗口管理器需要精确跟踪每个区域的无效状态（脏矩形），并管理绘制顺序、裁剪区域和多重缓冲。随意切换图层会破坏这些管理逻辑，导致后续的WM_PAINT调用在错误的图层上下文中进行，或者脏矩形计算错误，最终画面混乱。

4.2 父子窗口与图层：必须同层

原则二：子窗口必须和它的父窗口创建在同一个图层。

WM_CreateWindowAsChild不会检查这一点，即使你传入了不同图层的父窗口句柄，它也能“成功”创建。但后果是灾难性的：触摸事件无法正确传递，裁剪区域计算错误，子窗口可能根本显示不出来，或者出现在诡异的位置。

// 错误：父子窗口跨图层 GUI_SelectLayer(0); hParent = WM_CreateWindow(0,0,100,100,WM_CF_SHOW, _cbParent,0); GUI_SelectLayer(1); // 切换到了图层1 hChild = WM_CreateWindowAsChild(10,10,50,50, hParent, WM_CF_SHOW, _cbChild,0); // 子窗口在图层1，父窗口在图层0 // 正确：确保在同一图层创建 GUI_SelectLayer(0); hParent = WM_CreateWindow(0,0,100,100,WM_CF_SHOW, _cbParent,0); // 保持在图层0 hChild = WM_CreateWindowAsChild(10,10,50,50, hParent, WM_CF_SHOW, _cbChild,0);

最佳实践：在创建窗口前，显式地调用GUI_SelectLayer()选择目标图层，并确保后续创建的所有相关窗口（父、子、兄弟）都在这个调用之后、下次切换图层之前完成。

4.3 半透明效果与内存设备

原则三：正确处理Alpha通道，谨慎使用内存设备。

很多LCD控制器支持图层的Alpha混合。emWin默认行为是：当绘制一个带Alpha通道的位图（如PNG）或抗锯齿文字时，它会进行混合计算，并将结果写入帧缓冲区，最终不保留Alpha值。如果你需要图层混合，必须告诉emWin保留Alpha。

case WM_PAINT: { // 绘制一个半透明的覆盖层 GUI_EnableAlpha(1); // 启用Alpha混合 GUI_SetLayerMode(GUI_DRAWMODE_NORMAL); // 确保是正常混合模式 // 关键：在绘制前保留透明信息 GUI_PreserveTrans(1); // 告诉emWin，接下来的绘制需要保留Alpha通道 // 绘制带Alpha的位图或抗锯齿文字 GUI_DrawBitmap(&bmTransparentLogo, x, y); GUI_DispStringAt("Transparent Text", x, y+50); GUI_PreserveTrans(0); // 恢复默认 GUI_EnableAlpha(0); break; }

内存设备（Memory Device）：用于防止闪烁，它先在内存中绘制完整窗口，再一次性拷贝到显示层。在多图层环境下，内存设备必须创建在和目标窗口相同的图层。否则，内存中的像素格式可能不匹配，拷贝会导致颜色错误。

WM_HWIN hWin; // 假设是图层2上的一个窗口 GUI_MEMDEV_Handle hMemDev; case WM_CREATE: // 在窗口创建时，创建同图层的内存设备 GUI_SelectLayer(2); // 切换到窗口所在的图层 hMemDev = GUI_MEMDEV_Create(0, 0, 100, 100); // 尺寸与窗口匹配或更大 GUI_SelectLayer(0); // 切换回默认图层（如果需要） break; case WM_PAINT: // 使用内存设备进行双缓冲绘制 GUI_MEMDEV_Select(hMemDev); // ... 在内存设备上执行所有绘制操作 GUI_MEMDEV_Select(0); // 切回帧缓冲区 GUI_MEMDEV_CopyToLCD(hMemDev); // 拷贝到LCD（会自动处理图层） break;

4.4 多图层下的触摸输入处理

触摸控制器通常只报告一个物理坐标，它不知道你有几个图层。emWin默认将所有触摸输入路由到当前活动图层（通过GUI_PID_STATE结构体的Layer成员指定，通常在触摸中断服务程序ISR中设置）。

场景：你有两个图层，图层0是背景UI，图层1是一个半透明的浮动键盘。你希望点击键盘区域时，键盘响应；点击键盘以外的透明区域时，背景UI响应。

实现：这需要用到GUI_PID_SetHook()设置一个钩子函数。这个函数在触摸数据放入输入缓冲区前被调用，你可以在这里根据坐标判断点在哪个图层，并动态修改GUI_PID_STATE中的Layer索引。

static void _PID_Hook(GUI_PID_STATE *pState) { int x = pState->x; int y = pState->y; // 判断(x,y)是否在图层1的键盘非透明区域内 if (_IsPointInKeyboardOpaqueArea(x, y)) { pState->Layer = 1; // 强制将触摸事件分配给图层1 } else { pState->Layer = 0; // 否则给图层0 } // 注意：不要修改pState->x和pState->y，WM会根据Layer自动转换坐标。 } void main() { GUI_Init(); GUI_PID_SetHook(_PID_Hook); // 设置钩子 // ... 初始化图层和窗口 }

避坑指南：

性能：钩子函数会在每次触摸事件（按下、移动、抬起）时被调用，必须非常高效。
坐标系统：钩子函数收到的坐标是屏幕绝对坐标。你需要自己维护每个图层窗口的布局信息来进行命中测试。
默认回退：如果你的逻辑无法决定，就保持pState->Layer不变，使用默认图层。

4.5 配置选项与性能权衡

emWin提供了两个关键的多图层/高级特性配置宏，在GUIConf.h中定义：

#define WM_SUPPORT_NOTIFY_VIS_CHANGED 0 // 默认关闭 #define WM_SUPPORT_TRANSPARENCY 1 // 默认开启

WM_SUPPORT_NOTIFY_VIS_CHANGED：设为1时，窗口的可见性发生变化（如被其他窗口遮挡、显示/隐藏）会收到WM_NOTIFY_VIS_CHANGED消息。这是给高级应用用的，比如你用硬件解码器直接在帧缓冲区播放视频。当视频窗口被完全遮挡时，你可以停止解码以节省功耗；当它再次可见时，再恢复解码。对于普通UI，保持为0可以节省一点代码空间和消息处理开销。
WM_SUPPORT_TRANSPARENCY：如果你的应用完全用不到任何透明效果（包括半透明窗口、带Alpha的PNG图片、抗锯齿字体），可以将其设为0。emWin会移除所有相关的透明处理代码，能显著减少ROM占用并略微提升绘制速度。在项目初期就根据需求确定这个配置，中途更改可能需要调整大量绘制代码。

5. 消息、ToolTips与多图层协同的复杂场景处理

在实际项目中，上述功能往往是交织在一起的。这里分享一个我经历过的复杂场景处理经验。

场景：一个医疗设备主界面。图层0是静态背景和数据显示（频繁更新）。图层1是一个半透明的、带ToolTips的悬浮菜单面板，该面板可以通过触摸拖拽移动（使用Motion支持），并且面板上有一个实时刷新的波形小控件。

挑战与解决方案：

拖拽与图层：悬浮菜单在图层1。实现拖拽需要处理WM_MOTION消息。在WM_MOTION_INIT中，除了设置WM_CF_MOTION_R（如果支持旋转）和WM_MOTION_MANAGE_BY_WINDOW，还必须确保拖拽计算是基于图层1的坐标系统。在WM_MOTION_MOVE中，根据pInfo->dx, dy移动窗口时，调用WM_MoveWindow()，窗口管理器会自动处理跨图层的正确显示。
ToolTips与半透明：菜单按钮上的ToolTips创建时，父窗口句柄是图层1上的菜单窗口。由于菜单窗口是半透明的，要确保ToolTip窗口的背景色是不透明的（例如纯灰色），否则文字会难以阅读。可以通过WM_TOOLTIP_SetDefaultColor设置一个不透明的背景色。
实时波形与WM_PAINT：波形小控件在图层1的菜单面板上，需要每秒刷新30次。绝对不能在定时器中断里直接画。正确做法是：
- 在WM_CREATE中为波形控件窗口创建一个高速定时器（33ms）。
- 在WM_TIMER消息中，只是将新的波形数据点存入一个环形缓冲区，并调用WM_InvalidateWindow(hWaveWin)标记该窗口无效。
- 在波形窗口的WM_PAINT消息中，从环形缓冲区读取数据，绘制完整的波形曲线。这样保证了所有绘制都在WM管理的上下文中进行，即使波形窗口在图层1，也能正确绘制。
性能优化：图层1的菜单面板半透明，意味着其下图层0的内容变化会导致菜单区域不断被标记为无效并重绘。如果图层0的数据刷新很快，这会造成不必要的性能负担。优化方法是：将菜单面板设计为大部分区域不透明，仅边框有半透明效果。或者，精确控制图层0的无效区域，避免频繁覆盖菜单所在区域。
输入处理：由于菜单面板半透明，我们需要让面板透明区域下的图层0按钮也能被点击。这就要用到前面提到的GUI_PID_SetHook。在钩子函数中，判断触摸点是否在菜单面板的不透明控件（如按钮）上。如果是，将Layer设为1；否则，设为0。这样就能实现“点击按钮操作菜单，点击空白处操作背景”的复杂交互。