【Godot4.3】RenderingServer总结
概述
RenderingServer是Godot中“服务器”（*Server）单例中负责渲染的“服务器”。这里的“服务器”并不是网络服务器，而可以理解为底层服务或底层API的集合。
使用RenderingServer可以完全绕过场景和节点系统。如果场景系统是瓶颈所在，那么这样做就可以提升性能，否则无法提升性能。
因此对RenderingServer学习可以理解为对Godot底层渲染API的学习，学习的目的是绕过场景和节点系统进行渲染优化。
截止到Godot4.3，RenderingServer是一个拥有将近500个（我自己数的是495个）方法的庞大单例。但是其涉及的资源类型或对象就十来个，用面向对象写法的话，可能也就十来个类，但是肯能是为了性能考虑，RenderingServer采用了纯粹的函数形式。
为了尽量了解和掌握RenderingServer提供的功能，我们不得不使用分而治之的策略，采用分组和分类来探讨。
RenderingServer和RID
RenderingServer只有一个属性render_loop_enabled，用于开启或禁用渲染服务create_*()或*_create()：用来创建各种资源CanvasItem相关：如果你是基于一个场景，比如说一个Node2D或Control根节点，使用RenderingServer的话，就不需要考虑Viewport、Canvas的创建，因为你可以直接将操作对应到根节点，通过get_canvas_item()来获取它们对应的CanvasItem的RID。
什么是RID
RenderingServer中没有Node的概念，只有Resource的概念。- 创建
CanvasItem、Texture2D或者相机什么的，都是创建资源实例，创建的资源实例被分配一个唯一标识RID，RID内部本质是存储了一个int类型的值。 RenderingServer通过方法创建资源实例，并返回对应的RID而不是资源实例本身的引用。- 然后所有的操作都围绕着
RID展开。
为了避免内存泄漏，应该在使用完对象后调用free_rid()，因为直接使用RenderingServer时不会自动进行内存管理。
CanvasItem相关
CanvasItem是所有Node2D和Control类型的父类。在2D场景中，当然就要以CanvasItem的创建和操作为主要内容。
extends Node2Dfunc _draw() -> void:var canvas_item = RenderingServer.canvas_item_create() # 创建CanvasItem实例# 绘制圆RenderingServer.canvas_item_add_circle(canvas_item,Vector2(300,300),50,Color.AQUAMARINE)# 将CanvasItem实例添加到当前节点RenderingServer.canvas_item_set_parent(canvas_item,self.get_canvas_item())
你可以在远程模式下看到，场景根节点上，并没有添加多余的节点。因为CanvasItem本身就是一个不能当做节点添加的抽象基类。它既不是具体的Node2D，也不是Control节点。
甚至你也不能通过get_chidren()的方式获取它们，因为它们不被算作是节点。
print(get_child_count(true)) # 0
因此你可以将一个节点能够添加若干的CanvasItem理解为这个节点拥有了一个隐含的分层。
Godot不限制你在Node2D或Control及其任意子类型上使用RenderingServer。这也就意为着在编写自定义节点时，可以绕过创建具体的子节点，而直接使用更底层的API，而且可以批量创建和管理大量的CanvasItem。
绘图函数相关
canvas_item_add_*方法大多数都与CanvasItem的绘图函数相对应。
extends Node2Dvar tex:RID
const ICON = preload("res://icon.svg")func _draw() -> void:# 绘制Texture2DRenderingServer.canvas_item_add_texture_rect(self.get_canvas_item(),Rect2(0,0,200,200),ICON)