什么会导致 64 位 vista 上的重绘问题，而 .NET WInForms 中的 32 位不会? [英] What could cause redraw issues on 64-bit vista but not in 32-bit in .NET WInForms?
问题描述
在为 Any Cpu 编译以及为 x86 编译时会发生这种情况.除非调整大小，否则 GUI 的部分不会重绘，例如，如果主窗体最大化，一些控件不会随之调整大小，而其他部分则不会重绘并显示以前的内容.
这在 32 位机器上工作正常，包括 XP 和 Vista，但在 64 位 Vista(没有 x64 XP 用于测试)上，重绘无法正常工作.
有人知道从哪里开始追踪这个吗?
这发生在两台不同的机器上，至少我目前使用的那台机器有来自 NVidia 的最新驱动程序.
Edit2:在我的 64 位机器上运行 32 位 XP 虚拟机，并且应用程序在 VM 中没有出现重绘问题
Edit3:这可能是驱动程序问题，但我们不知道驱动程序是否或何时会解决该问题.一位同事说家里的 ATI 卡问题比 NVidia 少，但过去几个月我几乎每个月都更新我的视频驱动程序，但仍然没有解决，所以我们不能只是发布我们的产品并告诉我们的客户，有一天驱动程序制造商可能会解决这个问题.
有没有人对要避免的事情有任何见解?我们编译为 x86，我们所有的组件都是 x86.我似乎无法使用测试项目中的任何组件重现此问题，而且我在大多数组件论坛上都没有听到其他人报告这些问题，因此很可能这是我们正在做的事情.
这听起来很像 这个 问题.
在 Windows 上调整窗口大小时，您通常会得到一个链，其中每个窗口接收一个 WM_SIZE 消息，然后在其子窗口上调用 MoveWindow()(或类似的)，然后依次调用接收 WM_SIZE 等等.我确信 .NET 在幕后做同样的事情.
在 x64 上，Windows 限制此嵌套的深度，并且在某个点(12-15 个嵌套窗口)之后，它将不再发送 WM_SIZE 消息.x86 上似乎不存在此限制.此限制会影响在 x64 版本的 Windows 上运行的 x86 和 x64 代码.
这让我们困惑了很长时间，因为不同的 x64 安装会显示不同的症状.上面的 MSDN 博客帖子有一些可能的解决方法 - 我们最终使用辅助线程异步处理窗口大小，这相当巧妙地解决了问题.
This happens when compiling for Any Cpu as well as compiling to x86. Sections of the GUI doesn't redraw unless it's resized, for instance if the main form is maximized some of the controls don't resize with it, and others have sections that don't redraw and displays the what was previously there.
This works fine on 32-bit machines, both XP and Vista, but on 64-bit Vista (don't have x64 XP to test with) the redrawing just isn't working properly.
Anyone have any ideas on where to start tracking this down?
Edit: This occurs on 2 separate machines, and at least the one I'm currently on has the latest drivers from NVidia.
Edit2: Running a 32-bit XP virtual machine on my 64-bit machine and the application doesn't exhibit the redrawing issue in the VM
Edit3: It may be a driver issue, but we don't know if or when drivers will fix the issue. A co-worker says there's fewer issues with an ATI card at home than with NVidia, but I've been updating my video drivers pretty much monthly for the past few months and it's still not resolved, so we can't just release our product and just tell our customers that some day the driver manufacturers may get around to fixing this.
Does anyone have any insight on what things to try to avoid? We're compiling as x86 and all our components are x86. I can't seem to reproduce this issue with any of the components in test projects, and I haven't heard anyone else report these issues on most of the the component forums, so it is fairly likely that it's something we're doing.
That sounds horribly like this problem.
When resizing windows on Windows you typically get a chain where each window receives a WM_SIZE message and then calls MoveWindow() (or similar) on its children which in turn receive a WM_SIZE and so on. I'm sure that .NET does the same thing under the covers.
On x64, Windows limits the depth of this nesting, and after a certain point (12-15 nested windows) it will just not send the WM_SIZE messages anymore. This limitation does not appear to exist on x86. This limitation affects both x86 and x64 code running on x64 versions of Windows.
This foxed us for ages, as different x64 installs would show different symptoms. The MSDN blog posting above has some possible workarounds - we ended up using a secondary thread to do the window sizes asynchronously, this solved the problem fairly neatly.
这篇关于什么会导致 64 位 vista 上的重绘问题，而 .NET WInForms 中的 32 位不会?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
