复合应用程序块区域注入速度慢

发布于 2024-07-29 08:35:54 字数 460 浏览 8 评论 0原文

我使用复合应用程序块(“棱镜”)V2 构建一个 wpf 应用程序,并且遇到一个问题,即由模块注入的用户控件渲染速度非常慢。 用户控件包含一个包含约 2000 行的数据网格,并且控件呈现到屏幕上存在相当大的延迟。 最初我认为缓慢是由于 wpf 工具包数据网格控件本身造成的,但事实并非如此。 当我将包含数据网格 (TestControl) 的控件从外部模块移出并移入 shell 项目并直接从那里加载时,控件会立即呈现,没有任何问题。

我在模块中的 IModule 实现中使用以下代码将 wpf 用户控件注入到 shell 中

 this.regionManager.RegisterViewWithRegion("mainRegion", typeof(TestControl));

从 prism 应用程序中的其他模块加载控件时是否存在性能问题? 加载它们的最佳方式是什么?

谢谢

Im building a wpf app with the composite application block ("prism") V2, and Im having an issue where a user control that is injected by a module is very slow in rendering. The user control contains a datagrid with some 2000 rows in it and there is considerable lag in the control rendering to the screen. Initially I thought the slowness was due to the wpf toolkit datagrid control itself but this is not the case. When I move the control containing the datagrid (TestControl) out of the external module and into the shell project and load it straight from there the control renders immediately without any problems.

Im using the following code in the implementation of IModule in my module to inject the wpf user control into the shell

 this.regionManager.RegisterViewWithRegion("mainRegion", typeof(TestControl));

Is there performance issues when loading controls from other modules in a prism app? Whats the most optimal way to load them in?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

七颜 2024-08-05 08:35:54

这里的问题似乎是当通过后台线程的调度程序更新 UI 时,wpf 更新速度很慢。 我在 Codeplex 上继续了对话,并或多或少地整理了内容。

http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId= 64113

the problem here seemed to be wpf being slow to update when the UI is being updated vai the dispatcher from a background thread. I took up the conversation on codeplex and got it more or less sorted.

http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=64113

烂人 2024-08-05 08:35:54

这很可能是生命周期事件的产物。 在模块开始加载和注册之前,您的 shell 就会很好地显示。 如果你这样做,它会“看起来”需要更长的时间,因为你的 UI 中会出现一个大洞,直到模块初始化代码触发。

很多示例让您执行类似“Shell.Show();”的操作 在引导程序的 CreateShell 方法中,但您可能会考虑将对 Shell 的引用移至引导程序类的私有成员,并在其中调用 .Show() ,如下所示:

public class Bootstrapper : UnityBootstrapper
{
    Shell shell;
    protected override DependencyObject CreateShell()
    {
        shell = Container.Resolve<Shell>();
        return shell;
    }

    protected override void InitializeModules()
    {
        base.InitializeModules();
        shell.Show();

    }

我刚才尝试了这个,它绝对感觉像我的应用程序的性能得到了提升,所以我想我会自己做出这个改变。

如果您的模块需要很长时间才能加载,您可能还希望在 CreateShell 和 InitializeModules 之后显示启动屏幕。

It's likely this is an artifact of the lifecycle events. Your shell is going to display well before your modules start to load and register themselves. If you do this it will "appear" to take longer because your UI will appear with a big fat hole in it until the module initialization code fires.

A lot of the samples have you doing something like "Shell.Show();" in your CreateShell method of your bootstrapper, but you might consider moving the references to the Shell to a private member of your bootstrapper class and calling .Show() on it in, like this:

public class Bootstrapper : UnityBootstrapper
{
    Shell shell;
    protected override DependencyObject CreateShell()
    {
        shell = Container.Resolve<Shell>();
        return shell;
    }

    protected override void InitializeModules()
    {
        base.InitializeModules();
        shell.Show();

    }

I tried this just now and it definitely felt like my app got a performance boost, so I think I'll make this change myself.

If your modules take a really long time to load, you also might want to show a splash screen between CreateShell and after InitializeModules.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文