cocos2d界面渲染

渲染是visit函数来做的,

visit是先将不可见的节点和他所有的子节点都跳过,

然后再看节点的子节点是否为空,

如果为空的话直接看这个节点是否在摄像机可见范围之内,

如果在就渲染这个节点,

否则什么都不做。

如果子节点不为空,

就:
先将子节点排序,

通过zorder排序,

如果zorder相同就通过先后加入节点树的顺序排序,

排序好之后zorder是递增的,

先加入的也会再下面。
然后先绘制zorder小于零的,

再绘制自身,

再绘制zorder大于零的节点,

这个其实就是中序遍历节点树的过程。

时间: 2024-12-24 02:20:49

cocos2d界面渲染的相关文章

GNU/Linux下Freeplane的界面渲染问题

如下图所示,思维导图软件Freeplane在GNU/Linux下默认的界面渲染效果是很差的,即便将Preferences → Appearance → Antialias设置为Antialias all亦如此 查了一下,发现是Java的反锯齿效果没有打开的缘故.为此,需要在~/.bashrc对_JAVA_OPTIONS环境变量予以设置: export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dsun

Android 自定义可拖拽View,界面渲染刷新后不会自动回到起始位置

以自定义ImageView为例: /** * 可拖拽ImageView * Created by admin on 2017/2/21. */ public class FloatingImageView extends ImageView{ public FloatingImageView(Context context) { super(context); } public FloatingImageView(Context context, AttributeSet attrs) { su

iOS:使用模板引擎渲染HTML界面

在实际开发中,UIWebView控件接受一个HTML内容,用于相应的界面,下面是该API的接口: - (void)loadHTMLString:(NSString *)string baseURL:(nullable NSURL *)baseURL 由于HTML内容通常是变化的,所以我们需要在内存中生成该HTML内容.比较简单粗暴的做法是将该HTML的基本内容定义在一个NSString中,然后用[NSString stringWothFormat]方法将内容进行格式化,示例如下: //给对应的标

如何正确地写好一个界面

写界面可以说是每位移动应用开发者的基本功,也是一位合格移动应用开发者绕不过去的坎.但就如不是每一位开发者都能够成为合格的开发者一样,本人在 不同的团队中发现,甚少有人能够编写出合格的UI代码:而非常奇怪的是,在很多的开发者论坛上看到我们移动开发者更多关注于某个控件或者是动画,但却很少 看到深入剖析UI机制,指导UI开发的文章. 由于界面涉及到的方面实在过于广泛,本文不可能事无巨细,一一道来,所以本文先立足于点,深入剖析iOS UI系统中不被重视却非常重要的机制,帮助本文读者对iOS的UI系统有整

CodeFirst写界面——自己写客户端UI库

何谓CBS程序 CBS程序就是Client+Browser+Service的程序 纯CS程序写界面,有各种难处,那么我就在Client端引入Browser,让Browser渲染基于HTML的UI界面 何谓WUI 就算用用HTML渲染UI界面,那么开发人员还是要掌握HTML+CSS+JS的知识,这些知识还是比较复杂的 WUI库就是把HTML+CSS+JS封装成起来,组成一个界面元素库,(类似于Extjs和easyui) 意图是让开发人员就只要掌握C#代码,就能写出漂亮的UI界面 第一步:WUI库中

Vue源码翻译之渲染逻辑链

本篇文章主要要记录说明的是,Vue在Vdom的创建上的相关细节.这也是描绘了Vue在界面的创建上的一个逻辑顺序,同时我也非常拜服作者编码的逻辑性,当然或许这么庞大复杂的编码不是一次性铸就的,我想应该也是基于多次的需求变动而不断完善至现在如此庞大的结构和复杂度. 首先我们回顾 上一篇文章 中,讲到了Vue实例initMixin,就是实例初始化,但是,我们在看Vue的源码时,经常会遇到某个变量或方法,好像还没定义,怎么就用上了.那是因为,其实我们在使用Vue,即 new Vue(options) 的

WPF 解决界面卡死

工作中的项目,CS客户端会通过MQ接收前端设备发送的信息,之前测试的时候,由于测试的数据不大,没有进行压力测试,软件可以正常工作,随着项目现场设备数量的增加,CS客户端从MQ中订阅的数据量不断增加,最终导致,客户端界面卡死.原来的数据流程图如下: 这个数据流程,在数据不大的情况下,是没有什么问题,数据太多,从mq获取数据的流程太长,不管是Json反序列化,还是WPF界面渲染,都是耗时比较大.所以决定将数据流程改为如下所示: 修改后的方案,将原来的一个流程拆分两个流程,左边的流程只负责从mq取数据

iOS离屏渲染的解释

重开一个环境(内存.资源.上下文)来完成(部分)图片的绘制 指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作 意为离屏渲染,指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作. 红色代表GPU需要做额外的工作来渲染View,绿色代表GPU无需做额外的工作来处理bitmap. 界面渲染过程 RunLoop有一个60fps的回调,即每16.7ms绘制一次屏幕,所以view的绘制必须在这个时间内完成,view内容的绘制是CPU的工作,然后把绘制的内容交给GPU渲染,包括多个Vie

WPF 高性能位图渲染 WriteableBitmap 及其高性能用法示例

原文:WPF 高性能位图渲染 WriteableBitmap 及其高性能用法示例 WPF 渲染框架并没有对外提供多少可以完全控制渲染的部分,目前可以做的有: D3DImage,用来承载使用 DirectX 各个版本渲染内容的控件 WriteableBitmap,通过一段内存空间来指定如何渲染一个位图的图片 HwndHost,通过承载一个子窗口以便能叠加任何种类渲染的控件 本文将解释如何最大程度压榨 WriteableBitmap 在 WPF 下的性能. 本文内容 如何使用 WriteableBi