分页数据库其实就是两个生产者与消费者

再次看osg《最长的一帧》，因为分页数据库适合于PagedLod和ProxyNode,一般调试还得准备数据，比较麻烦。
突然想起，和我以前封装的引擎类似。分页数据库就是几个生产者与消费者。
回过头来看这个图。

看似复杂，实际上并不复杂。
如果简化，只需要一个数据请求列表和等待合并列表就够了。请求什么数据，就合并什么数据即可。当然，合并前清空数据。
也就是说，在请求数据时，用生产者和消费者的方式；同样，在渲染合并列表时，也用生产者和消费者的模式。

如果，再考虑效率，就要加上等待编译列表，把stateset和drawable加上去。
如果再正规点，就把合并队列前的每帧清空数据独立出来，即弃用对象列表。

这些工作肯定不能每帧进行，而是开一个线程，就是DataBaseThread::run()。值得注意的是，这个线程只对pagedLod和proxyNode起作用，单纯加个cow.osg,是进不去的。

准确地说，是两个线程，一个应对本地数据，一个应对网络数据。应对网络数据的，就要写本地Cache。

对于上面的请求数据，还有个时限问题，即：超时不处理。当然，弃用对象列表中无用的数据该扔还得扔。
有效处理的数据，按kdtree组织。

每帧是如何更新数据的呢？1，发送无用数据列表到线程；2，从线程接收合并数据列表

合并列表和请求列表中的数据是一样的么？
不一样。有三种数据不会合并。1，请求列表中超时的；2，请求列表中没有父节点的;3，请求列表中需要编译的（即，等待编译列表）过期的

等待编译列表中的数据如何编译?
两种方式1,图形设备线程处理；2，立即编译

明白了这些，再看下边这张图，就没那么困惑了，一切都是很自然。