dgorsman 发表于 2015-2-19 10:19:54

主显示器与辅助显示器与硬件加速有关 - 除非桌面在两个显示器之间“跨越”，否则第二个显示器上没有硬件加速。 如果命令行（作为单独的调色板）未停靠并在第二个监视器上，则可能也是如此。 这适用于XP，不确定它是否仍然适用于更新的OS / DirectX /硬件组合。

alanjt 发表于 2015-2-19 12:05:16

acad、outlook、chrome（可能会占用大量内存）、dropbox，没有什么真正超出标准的
它没有。我试过了，因为这应该是一个解决属性调色板滞后的方法（我必须保持关闭），但没什么区别
acad显示在主显示窗口中，命令行已停靠。

dgorsman 发表于 2015-2-19 14:07:17

不是一个解决方案，但出于好奇，延迟是否在命令行历史记录达到它存储的最大行时开始？
这是严格用于运行LISP例程，还是一般的命令和操作？如果是前者，可能有一些剩余的引用（以前的设置、临时列表等）没有正确清理。

alanjt 发表于 2015-2-19 15:01:32

这是一个有趣的想法。
一旦启动，它就会对所有内容产生滞后。LISP的原因只不过是一个疯狂的猜测。
就好像我已经达到了已执行命令的配额，然后它变得滞后（当命令行打开时）。差不多，在工作5-10分钟后，我将不得不关闭命令行。
虽然选择确实会产生滞后，但命令行（打印文本或输入）会变得缓慢。前几天，我正在我的基文件中绘制一些地役权，当我注意到它跟不上我的步伐时，通过承载命令完全退出了核心的民用3D线。

alanjt 发表于 2015-2-19 16:49:32

a
（gc）
是否有任何影响？-只是黑暗中的一刀。
页: 1 [2]
查看完整版本: 显著的命令行滞后