【问题标题】:discontinuous BitBlt capture不连续的 BitBlt 捕获
【发布时间】:2013-01-15 16:16:26
【问题描述】:

我在我的项目中大量使用 BitBlt。我创建了许多线程,并在每个线程中通过 BitBlt 捕获屏幕。除了以下问题之外,它现在运行良好且符合预期。

当用户单击正在运行的程序或例如已在任务栏上打开的资源管理器时,就会出现问题。您知道,当您单击任务栏上正在运行的程序时,它会最小化或出现在屏幕上。我正在谈论的问题恰好发生在这个过渡中。在那一刻,就像中断一样,所有线程停止捕获屏幕一秒钟,然后继续捕获。当您在音量控制窗口上向下或向上移动时,也会发生同样的事情。您能否解释一下为什么会发生这种情况以及如何防止这种情况发生?

谢谢。

【问题讨论】:

  • 这几乎肯定是由 Aero 引起的。您不再使用 BitBlt 读取视频内存,Aero 合成位图。当它显示窗口动画时,它会暂时停止执行此操作。当然,这没有简单的解决方法。
  • 不。航空已关闭。这在没有航空的情况下发生。还是谢谢。

标签: windows api capture interrupt bitblt


【解决方案1】:

这可能是日程安排问题。当您激活一个应用程序时,它的优先级会得到短暂的小幅提升(因此它在 UI 中看起来是响应式的)。这种提升可能会持续与动画一样长,并且会暂时抢占您的屏幕捕获线程。

桌面管理器也有可能正在序列化内容,而您的 bitblts 只是停滞不前,直到动画结束。即使您关闭了 Aero,我相信 desktop window manager 可能仍处于合成模式,这与 Hans Passant 在 cmets 中描述的效果相同。

如果您想从屏幕上制作视频,我认为依靠 GDI 是不可能的。我强烈建议阅读有关桌面窗口管理器的信息。例如,这个caveat 直接适用于你正在尝试做的事情:

避免读取或写入显示 DC。虽然受 DWM 支持,但由于性能下降,我们不建议这样做。

当您使用 GDI 尝试读取屏幕时,DWM 必须停止正在执行的操作,可能会将桌面的新副本渲染到视频内存,并将数据从视频内存复制回系统内存。有可能 DWM 将这些请求视为优先级低于正在进行的动画的请求,因此当它响应 BitBlt 时,动画已经结束。

这个question 建议带有屏幕捕获过滤器的 DirectShow 可能是要走的路。

【讨论】:

    猜你喜欢
    • 2011-01-29
    • 2016-02-13
    • 1970-01-01
    • 1970-01-01
    • 2015-01-02
    • 2012-12-10
    • 2013-01-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多