调试最长的一帧(第十天)

本文主要介绍了OSG更新回调,其由专门访问器负责场景图形更新遍历,与事件回调调用频率不同。还阐述了osg更新遍历函数的工作,包括处理更新回调、更新摄像机位置等。此外,讲解了更新工作队列、从摄像机更新,以及场景筛选设置和剔除方式。

依照惯例,先看总体流程

到了更新回调

一边抄一边记忆

OSG更新回调的作用与事件回调有类似之处,由专门的访问器对象_updateVisitor负责场景图形更新遍历

所有的节点和Drawable几何体对象都可以使用setUpdateCallback设置更新回调

 

通过重载NodeCallback::operator()或者Drawable::UpdateCallback::update函数,可以在回调对象中添加自定义的工作。

 

 

更新回调与事件回调最大的不同在于:每当一个用户交互或系统事件产生时,每一个节点(以及Drawable对象)的事件回调都会被调用一次;而节点(以及Drawable对象)的更新回调只会在每帧中被调用一次。这一区别决定了我们应当在什么时候使用事件回调,什么时候使用更新回调。

osg的更新遍历函数updatteTraversal在系统每帧的执行过程中,除了处理用户的更新回调对象外,还要负责更新摄像机的位置,并且更新分页数据库DatabasePager和图像库ImagePager的内容。流程如下

空的。。。。。。。

 

 

 

由于电子书后面有详细解释,所以这里就不多调试了。在第11天调试进去。

一般operation对象可以用来处理与图形设备以及opengl底层API相关的工作,不过用户级的工作在这里实现也没有问题。

先说的更新工作队列_updateOperations。更新工作需要继承osg::Operation并重写operator()操作符,以实现一些特定的用户操作。

这里是个纯虚函数,需要重载。

这里还举了个例子,定义场景预处理

可以写入多组更新处理器

也可以移除

接下来是从摄像机_slaves的更新

接下来论述了从摄像机组各个从摄像机的投影矩阵和观察矩阵分别是主摄像机的投影矩阵和观察矩阵再各自加上一个偏移量,场景筛选设置也是从主摄像机继承的。

设置从摄像机Cullsettings的继承掩码

 

这里可以看到cullsettings有很多种场景筛选设置选项。

 

先说如何设置这些cullsettings的继承掩码

看看如何使用的。

咦,camera在用。看看camera类

当然是osg::Camera派生于osg::Cullsettings类了

现在看看有多少种剔除方式,跟过去这个枚举类型。

这里有几个设置项

背面裁剪

剪切平面

细节筛选判断对象是否足够细微

如果怕忽略掉细节,则设置最小的包围盒

聚集筛选

 

设置一种或多种筛选方式可以使用CullSetting::setCullingMode函数,(采用“或”运算来指定多种筛选方式),如果希望暂时屏蔽某一种筛选方式,则可以类似

camera->setCullingMode(camera->getCullingMode() & ~osg::Cullsetting::SMALL_FEATURE_CULLING):

有关各种筛选方式的详细算法,在CullingSet::isCulled()

<think> 嗯,用户的问题是关于关机充电后再开机时显示第一帧时间慢的原因和解决方法。这个问题涉及到系统启动流程和硬件初始化,需要结合多个引用内容来分析。 用户提供的引用内容很丰富。引用[4]详细描述了系统启动流程,将开机分为OS层(UBOOT/kernel/init)、Android层和主界面三个阶段。引用[1]提到时间同步服务的问题,引用[2][3]则重点讨论了关机充电动画的实现机制。引用[5]还补充了硬件供电的细节。 从这些信息看,第一帧显示延迟可能发生在几个关键环节:最可能是Android服务初始化阶段耗时过长,特别是充电动画服务(引用[2][3])和系统服务(引用[1])的启动;也可能是硬件供电延迟(引用[5]);或者是内核驱动初始化问题。 用户可能是个Android系统开发工程师,正在调试启动性能。ta的提问很专业,直接定位到“第一帧显示”这个具体指标,说明对启动流程有基本了解。不过问题描述比较简洁,可能需要更具体的日志信息才能精确定位。 解决方法应该分层次:先确认是软件还是硬件问题。软件层面重点优化充电动画服务(参考引用[3]的旋转设置逻辑)和时间服务;硬件层面检查供电时序。如果用户能提供bootchart或systrace日志会更容易定位瓶颈。 考虑到用户的技术背景,回复时需要给出可操作的内核参数调整建议,比如跳过充电动画、限制启动进程等实际优化手段。同时提醒关键日志位置,方便ta进一步分析。 </think> 根据引用内容和系统启动机制分析,关机充电后开机显示第一帧时间慢的原因及解决方法如下: --- ### **原因分析** 1. **充电动画服务延迟** - 关机充电时系统需加载充电服务(如 `charge` 或 `charging_animation`)[^2][^3],这些服务初始化耗时较长(如屏幕方向计算、动画资源加载),导致开机后第一帧绘制延迟。 - 引用[3]显示:充电动画需通过 `anim_fb_init()` 计算屏幕方向(如 `phical_screen.rotation` 的值),若逻辑复杂或资源加载慢,会阻塞显示流程。 2. **系统服务初始化冲突** - 关机充电模式下,系统以 `charger` 模式启动(引用[4]),但开机时需切换回正常模式。若充电服务未完全释放资源(如未关闭图形缓冲区),会与开机动画服务冲突,导致第一帧等待。 3. **硬件供电时序问题** - 引用[5]指出:充电芯片(如MT6305N)需输出多路电压(VCORE、VDD等)。若电压上升缓慢或时序不同步,显示屏供电延迟会导致第一帧显示滞后。 4. **时间同步服务未就绪** - 引用[1]提到时间服务(如 `Windows Time`)未启动时,系统时间显示异常。类似地,若开机时显示服务依赖的计时模块未初始化,会延迟第一帧渲染。 --- ### **解决方法** #### 1. **优化充电动画服务** - **精简动画逻辑**:修改 `charging_animation.cpp`,减少旋转方向计算(如固定 `phical_screen.rotation` 值,引用[3])。 - **预加载资源**:在充电完成前预加载开机所需资源,避免开机时重复初始化。 ```c // 示例:固定屏幕方向为270度(横屏) phical_screen.rotation = 270; // 替换原分支逻辑 ``` #### 2. **分离充电与开机服务** - **强制释放资源**:在充电结束、准备开机前,主动释放图形缓冲区并关闭充电动画服务[^4]。 - **独立启动模式**:确保系统从 `charger` 模式切换到正常启动模式时,重新初始化显示服务(引用[4]的 `androidboot.mode` 切换)。 #### 3. **调整供电时序** - **优化PMIC配置**:检查充电芯片输出电压时序(引用[5]),确保显示屏供电优先启动。 - **增加电压监测**:在驱动层添加供电就绪检测,延迟显示初始化直至电压稳定。 #### 4. **启用显示服务优先级** - **提升显示进程优先级**:在 `init.rc` 中为开机动画服务设置高优先级: ``` service bootanimation /system/bin/bootanimation class main user graphics group graphics priority -10 # 提高优先级 ``` - **禁用非关键服务**:延迟启动时间同步等非必要服务(引用[1]),确保显示服务优先调度。 --- ### **验证建议** 1. **抓取开机日志**: ```bash adb logcat -b events | grep "boot_progress" ``` 检查 `boot_progress_start` 到 `boot_progress_enable_screen` 的时间间隔。 2. **使用性能工具**: - 通过 `systrace` 分析显示服务阻塞点。 - 检查内核启动时序:`dmesg | grep "display_power"`。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值