d7s*_*rai 11 c++ windows winapi paint direct2d
令我很生气的是,在Windows中调整窗口的大小并不像我希望的那样"平滑"(Windows程序通常就是这种情况,而不仅仅是我自己的.Visual Studio就是一个很好的例子).它使操作系统及其程序感觉"脆弱"和"便宜"(是的,我关心程序和用户界面的感觉,就像我关心关闭车门的声音和感觉一样.这是构建的反映质量),在我看来影响整体用户体验,最终影响品牌的感知.
重新调整大小时,重新绘制窗口内容无法跟上鼠标移动的步伐.每当我调整窗口大小时,都会出现"口吃"/"闪烁"效果,这似乎是由于在绘制新的已调整大小的内容之前,在新的已调整大小的窗口框架中重绘了窗口的先前大小内容.
我正在构建一个使用Direct2D 1.1绘制UI的Win32应用程序(x64),并且考虑到Direct2D的速度,我认为在2014年操作系统中不应该有这样的工件.我自己在Windows 8.1上,但是目标是Windows 7及以上版本的应用程序.
当最大化小窗口时,"先前大小"效果尤其明显(因为窗口大小的差异足以容易地对比旧内容的图像,因为它在较大窗口的左上角短暂闪烁与新内容随后被涂在上面).
这似乎是正在发生的事情:
我想知道是否有任何方法可以缓解这种情况(即摆脱第4步) - 例如通过拦截Windows消息 - 并避免在最终重新呈现之前使用旧内容重新绘制新大小的窗口新内容发生了.这就像Windows窗口重绘自己,使用已有的任何图形,之前很难要求我提供WM_PAINT消息或类似的更新内容.
可以吗?
编辑:似乎 WM_WINDOWPOSCHANGING/WM_SIZING 提供了对新大小数据的"早期访问",但我仍然没有设法抑制旧内容的绘制.
我WndProc看起来像这样:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_ERASEBKGND:
return 1;
case WM_PAINT:
PAINTSTRUCT ps;
BeginPaint(hWnd, &ps);
D2DRender();
EndPaint(hWnd, &ps);
return 0;
case WM_SIZE:
if (DeviceContext && wParam != SIZE_MINIMIZED)
{
D2DResizeTargetBitmap();
D2DRender();
}
return 0;
case WM_DISPLAYCHANGE:
D2DRender();
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, message, wParam, lParam);
}
Run Code Online (Sandbox Code Playgroud)
窗口没有CS_HREDRAW或没有CS_VREDRAW设置.交换链是双缓冲的,并且Present使用SyncInterval = 0进行调用.
我知道每次窗口大小更改时重新创建交换链缓冲区与静态窗口表面上的普通重绘相比会产生一些开销.然而,"口吃"并非由此引起,因为即使在禁用缓冲区大小调整并且在窗口大小调整期间简单地缩放现有窗口内容时也会发生这种情况(尽管这确实使得它随着鼠标移动而保持更好).
| 归档时间: |
|
| 查看次数: |
4368 次 |
| 最近记录: |