代码之家  ›  专栏  ›  技术社区  ›  Quibblesome

紧凑的框架-轻量级的图形用户界面框架?[关闭]

  •  4
  • Quibblesome  · 技术社区  · 16 年前

    CF上的WinForm有点重,初始化许多Windows句柄需要很长的时间和内存。另一个问题是缺乏内置的双缓冲和对UI呈现缺乏控制,这意味着在处理器密集型操作期间,UI可能会让用户盯着半呈现的屏幕。好极了!

    为了缓解这个问题,我将寻求一个轻量级的控制框架,是已经有了一个框架,还是必须自制?

    我指的是一个轻量级的控件库,它可以完全控制控件的绘制,并且不使用许多昂贵的窗口句柄。

    注意:请不要建议我在UI线程上运行太多。那就是 案件。

    4 回复  |  直到 11 年前
        1
  •  2
  •   Tim Clem    15 年前

    前几天我遇到了这个问题,至少作为一个起点,这可能会有所帮助: Fuild - Windows Mobile .NET Touch Controls . 外观和感觉不错,但没有设计时支持。我对内存占用等不太了解,但所有内容都是双缓冲的,而且性能似乎不错。

        2
  •  1
  •   SmacL    16 年前

    好吧,只是我头脑中的一个想法…

    如何在您的应用程序中创建一个同步对象,例如在您的工作线程和GUI线程之间共享的关键部分或单个锁。覆盖绘制。当您开始绘制时,阻塞所有其他线程,这样在它们占用CPU的同时,您就不会剩下一个半绘制的屏幕。

    (当然,这假定向用户展示漂亮的图片是您需要的最重要的事情;)

        3
  •  0
  •   Chris Karcher    16 年前

    速度有点慢,您无法控制画图事件,因此在处理器密集型操作期间,用户界面可能会让用户盯着半渲染屏幕。

    在UI线程上执行昂贵的任务通常是一个坏主意。为了保持用户界面的响应性,这些任务应该由 worker thread

        4
  •  0
  •   Joel Coehoorn    11 年前

    实际上,可以覆盖绘制事件。

    其思想是将长时间运行的操作卸载到一个单独的线程。实际上,这与任何其他事件驱动框架都没有区别。 任何东西 这取决于对油漆事件的处理。

    此外,没有系统可以让您确定何时引发绘制事件。这种事件通常是由窗口管理器层引发的,它在应用程序(甚至框架)之外。你可以自己处理这件事,有时也不工作,但我不推荐。