我正在考虑实施我自己的（玩具）MVC框架，主要是为了练习并享受乐趣。我过去曾使用过这样的框架，但在考虑如何解决这个问题时，出现了几个问题。 所以让我最困惑的是我应该如何处理视觉元素的绘制。我的想法是在项目的类中实现每个项目的绘图逻辑，将它们组织成树形结构，就像在WPF中一样，并传递某些画布，元素可以在遍历树时绘制。 我有疑虑，我是否应该在整个视觉树上传递画布。另一个有趣的事情是处理重叠元素并首先绘制。我认为视觉树将通过按照它们在深度优先搜索中出现的顺序绘制elemtns来处理。但后来我认为最新的元素应该在顶部，无论它与树中的根有多接近。
所以基本上我无法真正找到关于绘制元素的实现最佳实践或细节的任何内容，我可以对此使用一些友好的建议，或者如果你可以指出一些涵盖它的材料，它将是非常欢迎。
答案 0 :(得分：1)
MVC模式通常不会解决这些细节问题。它最终归结为将问题分解为三个广泛的领域：数据和逻辑，用户输入和用户输出。
但是，我怀疑，我是否应该通过画布 整个视觉树。
为什么？从绩效或耦合/责任的角度来看？
如果它的表现，这是一个非常可靠的开始。默认情况下，您必须下降树并重新绘制所有内容，但可以通过将层次结构转换为加速器并跟踪需要重绘屏幕/画布/图像的哪些部分来缓解这种情况（＆＃34;脏区域＆ ＃34）。只下降与这个脏区域重叠的分支。
对于脏区域，您可以将画布分解为网格。由于小部件需要更新，请将它们占用的区域标记为需要重新绘制。仅重绘小部件占用那些标记为需要重绘的网格单元格。如果你想真正精心设计并减少过度抽取，你可以使用四叉树（但对于除了最动态的系统之外的所有系统，除了精心制作的动画内容和类似的内容之外，通常都会出现过度杀伤）。
可能很容易让这个问题更容易解决，以双重缓冲一切，并让孩子吸引他们的父母＆＃39;画布，但这是一种获得一些即时性能的途径，以换取设计级别的大型性能障碍，以内存消耗和缓存效率的形式。我不推荐这种方法：双重缓冲窗口内容以避免闪烁伪影，但不是内部的每一个控件。
如果它涉及耦合和责任，通常从UI上下文过度杀戮试图将小部件的呈现与小部件本身分离。通过实体组件系统将渲染与实体分离是常见的，它们将提供渲染组件（通常以哑数据的形式）并将渲染功能推迟到系统，但是那些需要大量工作才能实现极大的灵活性在这种情况下你可能永远不会需要它。
另一个有趣的事情是处理重叠元素和 哪个先画。我认为视觉树会处理这个问题 通过按照深度优先搜索中出现的顺序绘制elemtns。 但后来我认为无论是最新元素都应该在最顶层 它与树中的根有多接近。
树不一定是这种僵硬的东西。您可以将兄弟姐妹发送到子列表的前面或后面以影响绘图顺序。通常情况下，z顺序变化不会频繁发生，并且大部分时间你都可以通过这种方式获得更好的效果，而不是在渲染时动态地对绘图进行排序。
大多数情况下，我只是建议保持简单，特别是如果这是您第一次尝试构建通用MVC框架。你更容易犯错误，把事情弄得太复杂，把自己画在角落里。简单的设计是柔韧的设计。