我正在尝试实现一个显示服务器发送的栅格数据的图层。 服务器协议发送的数据在广泛使用的浏览器中没有内置支持（这是jpeg2000数据）。 因此，我自己对数据进行解码，然后让它显示给Cesium。
是什么让它变得有点复杂：
服务器是有状态的，因此客户端和服务器都应该维护一个通道。该频道与单个感兴趣区域相关联。该区域可能随时间而变化，但在每个时间点，只有一个区域，服务器在该区域上发送数据。 我可以在会话中使用一些频道，但是服务器在频道数量非常少的情况下表现不佳。
感兴趣的区域具有统一的分辨率（因此对3D有问题）。
服务器支持逐步发送数据，逐步提升质量（＆＃34;质量层＆＃34;在jpeg2000中），由于网络资源非常少，我想使用该属性。
解码在CPU时间方面很重。
作为第一阶段，我实现了一个ImageryProvider，它只为渲染引擎请求的每个图块创建一个通道。它工作但创建了太多的连接，我不喜欢渐进式渲染。此外，性能很差，这个问题几乎可以通过实现优先级机制来解决，该机制首先在Cesium查看器的视图区域中解码了切片。
接下来，我实现了一个自渲染的栅格＆＃34;层＆＃34;它根据视图区域改变频道的感兴趣区域。然后解决了多通道问题，我很喜欢渐进式渲染。但是我遇到了以下问题：
一个。我用来显示解码像素的方法是实现一个图像提供器，它显示带有解码像素的单个Canvas。每次更新图像（重新定位或逐步解码）时，我都必须删除旧的图像提供程序并将其替换为新的图像提供程序。我想这不是正确的做这种事情的方法，并且当用新的提供者替换旧的提供者时，它可能会导致一些不良的行为，例如错误的z排序等。其中一些问题可以通过使用原语来解决。使用Image材质，但后来我必须使用数据URL形式的图像。这样做会降低性能，因为它会导致很多从画布到数据URL的转换。
湾我必须编写特殊代码来理解视图区域，以便将其发送到服务器（使用pickEllipsoid和类似功能）。我想这段代码是在Cesium引擎中完成的重复。另外我在一些讨论中看到2D中不支持pickEllipsoid。一般来说，我很高兴有一个为我计算视图区域的功能，而不是自己实现该代码。
℃。我实现它的方式引发了API问题：与Cesium添加和删除图像提供程序（addImageryProvider（）方法和removeLayer（））的优秀API相反，在我的实现中，用户只需要使用我向他公开的方法（例如，接受Viewer作为参数的方法add（））。
d。在3D模式中，当分辨率不均匀时，图像在近区域中不清晰。我知道这是一个固有的问题，因为我的服务器工作方式，只需指出它。
我认为我在这里真正缺少的是一种实现插件的方法，该插件比ImageryProvider的界面更强大：实现自渲染的栅格图层，它从渲染引擎接收视图区域更改事件可以决定何时以及如何刷新其瓷砖。 另一个替代方案（对我来说更好，但我认为其他人可以重复使用），是将视图区域中的切片列表暴露给ImageryProvider实现。
应对这种情况的正确方法是什么？