TWebBrowser 仅在 Delphi 中控制性能缓慢答案

【问题标题】：TWebBrowser control slow performance only in DelphiTWebBrowser 仅在 Delphi 中控制性能缓慢
【发布时间】：2014-09-19 13:40:12
【问题描述】：

谁能解释一下为什么 TWebBrowser 控件在所有 XE 版本的 Delphi 上运行如此缓慢，包括 XE5 和可能的 XE6？要对此进行测试，您需要创建一个新的 Delphi 项目并将 TWebBrowser 控件放入其中。在表单展示活动中，导航到此网站：

http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html

请在 Windows 7 或更高版本上进行测试。导航完成后，运行 setImmediate 测试并观察结果。完成测试将花费大量时间。完成此操作大约需要一分钟。

当您打开真正的 Internet Explorer 浏览器并执行相同操作时 - 测试将立即完成（约 200 毫秒）。

一些额外的奇怪信息：

当您在旧版本的 Delphi（准确地说是 Delphi 7）上重新创建此过程时，Web 控件会以应有的速度运行，并且测试会立即完成。但是 HTML5 速度测试仍然会运行缓慢（此页面上的替代测试）。

另一个奇怪的事情是，在 C++ Builder 上可以看到同样的缓慢行为，但在 Visual Studio 产品中却没有。微软是否故意放慢 Embarcadero 产品中的 TWebBorwser 速度？我不敢相信。

我试图用不同的方法来克服这个问题，例如：

在注册表中尝试不同的功能选项，例如： FEATURE_GPU_RENDERING， FEATURE_BROWSER_EMULATION (11001), FEATURE_ALIGNED_TIMERS（未记录的选项）， FEATURE_ALLOW_HIGHFREQ_TIMER（未记录的选项），
设置 timerBeginPeriod(1) - 无效。

如果有人知道如何解决此问题，请与我分享此信息。

更新1 如果有人在乎，我制作了独立的测试应用程序。它可以在这里下载：http://mp.org.pl/download/ietest.zip 它包含源代码和带有 htm 文件的 exe 应用程序。 HTM 文件包含一些 js 程序，它在独立 IE 中的运行速度比在 TWebBrowser 控件中快 10 倍。它使用 setImmediate 作为测试（与上述测试中使用的过程相同）。但是用这种方式进行测试会更容易。

【问题讨论】：

我的猜测是 IE 在嵌入到您的应用程序时会隐式使用兼容性视图。检查您的注册表配置并了解如何使您自己的应用程序具有 IShellDocView 的兼容性视图设置的显式配置。兼容性视图可能导致使用古老的慢速 JavaScript 或 HTML 引擎，相当于 IE 7 或 IE 8，而不是现代 IE。您在 FEATURE_BROWSER_EMULATION 项目上走在了正确的轨道上，但您没有具体说明您尝试了什么、什么值等。
当您使用 TEmbeddedWB 时也会出现这种行为吗？ cf：github.com/danielfrimerman/Delphi-EmbeddedWB-XE3 或我的版本：bitbucket.org/wpostma/tembeddedwb
您可以发布 SSCCE 吗？
我测试了所有的兼容模式，你也可以自己检查。我指定我使用了 11001 设置（这是强制的 IE11）。这些设置都没有给出任何结果 - 但它们是有效的）。事实上，我测试了你的组件，结果同样糟糕。非常奇怪的是，用 Delphi 编写的旧编译版本的应用程序（它们都没有对注册表进行任何更改）工作得很好。该问题仅出现在 XE 版本的 Delphi 及更高版本上。 Delphi chromimum 项目提供了非常好的性能，但我不能在我的项目中使用它。我需要 TWebBrowser 来完成这项工作。
SetImmediate 是经典的 MS hack。毫不奇怪，它在这种情况下不能按预期工作。试试这个 --> 开始测试，拖动表单的窗口，然后看着测试突然完成。性能似乎与主机应用程序消息循环的繁忙程度有关。这种行为在 C#(VS2010) 中对我来说也是一样的——Windows.Forms.WebBrowser 控制。 Internet Explorer 本身可能会在内部执行某些操作来润滑 SetImmediate 的功能。至于为什么它似乎在 D7 中工作......谁知道呢？？

标签： performance delphi twebbrowser

【解决方案1】：

我还可以看到描述的行为（在您的原始帖子和 cmets 中）。我有一些想法，但不一定是答案。

WebBrowser 控件和 IE 之间的性能应该有所不同，部分原因是您的 Delphi 应用程序需要内置对 IE 开箱即用支持的某些功能/API 的支持。

例如，WebBrowser 控件会触发与tabbed browsing（旧但相关）相关的通知，但它本身并不处理这些通知或更新 UI。您必须自己响应通知并绘制标签。默认情况下，IE 是硬件加速的，并使用 Delphi 的 VCL（出于资源/性能）原因可能不直接支持的某些 Windows API。（硬件加速可能会导致您注意到的一些性能差异。）

（并且，作为记录，我不相信 IE 和 WebBrowser 控件之间的差异列表曾经被记录在案。我当然不记得在投资组合中看到过。）

此外，各种功能控件的默认值因 IE 和托管 WebBrowser 控件的应用程序而异。部分原因源于 IE 需要强调性能而不是兼容性，而应用程序通常需要强调兼容性而不是性能。您可能希望查看feature control reference 以了解您是否需要为您的应用启用其他 FCK。

其次，你的循环很紧，也许太紧了。您有一个请求堆积在较早的请求上，并且您并没有真正留下太多的处理空间，即使使用 setImmediate。（IIRC，我们真的不应该对 setInterval 使用小于 250ms 的任何东西，而不会冒着因请求数量过多而影响性能的风险。）setImmdiate 参考中的评论。页面提供了一些指导，requestAnimationFrame 上的这篇文章也提供了一些指导。

拖动窗口似乎可以提高性能的一个原因可能是窗口拖动重绘请求的优先级。它们可能会迫使您的循环保持足够长的时间（甚至中断）以允许处理其他事件。如果不使用调试器跟踪系统，这很难说。

您是否曾经必须将 application.processMessages() 添加到您的 Delphi 应用程序，以便让系统有机会处理您已经分配的工作？考虑到您的测试性质，类似的需求可能会发挥作用。

性能测试和时间安排是一件棘手的事情。您需要确保测试不会产生过多的开销，以免干扰您尝试执行的实际工作。

最后，当页面加载到您的项目中时，有一些关于页面文档模式的问题。当我第一次开始处理您的示例时，除了 IE5 怪癖模式（非常慢）之外，我无法让 project4 加载 slowtest.html。以下是最终开始为我工作的内容：

<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ --> 
<html>
<head>
  <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
  <script type="text/javascript">
  ...

（注意，我删除了您最初的 doctype 声明并重写它以解决 F12 工具调试器报告的语法错误。）

这里有几个风格要点：

我使用mark of the web 在 Internet 区域加载页面。我发现这使得在边缘模式下加载页面更容易，因为默认情况下，Intranet 区域中的页面在兼容性视图中加载（除非您以不同方式映射区域）。
与 x-ua 兼容的标头必须是头块中的第一个标头。它可以跟随标题，但not much else。
在风格上，这些天元素需要以小写形式指定。不遵循current conventions 可能会强制解析器回退到支持约定的早期渲染。

一旦我能够在运行时控制 documentMode，我发现了我预期的结果：旧的文档模式运行得更慢。我还发现使用 requestAnimationFrame 而不是 setImmediate 可以带来更好的性能，但也几乎立即浮出水面。

最后，这可能是测试突出问题的情况，但不一定是您要解决的问题。（在此处插入 Inigo meme。）我知道您正在尝试解决瓶颈。你确定你找到了正确的瓶颈吗？

您可能无法复制本机浏览器的相同性能，但也许您可以重构代码以充分执行而无需额外开销？使用worker 或其他一些实现技术可以更好地处理任何事情吗？

希望这会有所帮助...

【讨论】：