CN110609677A - 一种基于WebGL的图形绘制方法、装置及系统 - Google Patents

Abstract

本申请公开了一种基于WebGL的图形绘制方法、装置及系统。该方法包括：服务器接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；所述服务器解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；所述服务器将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。通过该技术方案，可以解决图形绘制效率较低的问题，提高兼容性，扩展JS项目的应用范围。

Description

一种基于WebGL的图形绘制方法、装置及系统

技术领域

本申请涉及计算机图形绘制技术领域，尤其涉及一种基于WebGL的图形绘制方法、装置及系统。

背景技术

在网络游戏、动画展现等应用场景中，终端设备需要进行大量的多维图形(比如2D图形或3D图形)的绘制工作。图形绘制的快慢在较大程度上决定终端设备上的各种应用、程序对用户操作的响应速度，进而影响到该应用或程序的用户使用量。为提高图形绘制效率，在不依赖于浏览器为载体的情况下，一般在终端设备上使用专门开发的运行器(RunTime)，如图1，运行器的核心组成部分包括JS解析引擎和C++引擎框架，前者用于对JS项目中的指令集进行识别、解析，后者用于调用封装的C语言函数对指令进行执行操作。运行器运行JS代码(JavaScript语言编写的代码)形成的JS项目时，由运行器的JS解析引擎对JS代码项目中的指令集进行解析，然后将解析后的各条指令以“压栈”方式推送到C++引擎框架中执行，再通过OpenGLES进行渲染，最终完成预定图形的绘制工作。

在大多数情况下，上述方式能够在终端设备上顺利完成图形绘制工作，但是，基于终端设备的运算能力，JS项目的整体运行效率低下、资源消耗量较大，导致终端设备短时内发热量过大，尤其终端设备为iOS设备时，由于JIT功能被禁用，iOS设备执行JavaScript脚本的效率更为低下。此外，由于不同的终端设备本身的差异，导致JS项目的运行效率各不相同，制约着JS项目的广泛应用。

发明内容

本申请实施例提供一种基于WebGL的图形绘制方法和装置、系统，以提高或改善图形绘制的效率，减少发热量，促进JS项目的广泛应用。

一方面，本申请实施例提供的基于WebGL的图形绘制方法，包括：

服务器接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

所述服务器解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

所述服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。

另一方面，本申请实施例还提供另一种基于WebGL的图形绘制方法，该方法包括：

终端设备通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

所述终端设备接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

所述终端设备执行所述指令流，以实现目标图形的绘制。

再一方面，本申请实施例提供基于WebGL的图形绘制装置，该装置位于服务器侧，其特征在于，包括请求接收单元、解析执行单元和指令发送单元，其中：

请求接收单元，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。

又一方面，本申请实施例还提供另一种基于WebGL的图形绘制装置，所述装置位于终端设备侧，其特征在于，包括请求发送单元、指令接收单元和指令执行单元，其中：

请求发送单元，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元，用于执行所述指令流，以实现目标图形的绘制。

再一方面，本申请实施例提供的基于WebGL的图形绘制系统，包括：所述系统包括服务器和终端设备，

所述服务器包括请求接收单元、解析执行单元和指令发送单元，其中：

请求接收单元，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制；

所述终端设备包括：请求发送单元、指令接收单元和指令执行单元，其中：

请求发送单元，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元，用于执行所述指令流，以实现目标图形的绘制。

又一方面，本申请实施例提供另一种基于WebGL的图形绘制系统，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的方法的步骤。

再一方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例提供的技术方案在服务器接收到终端设备发送的对JS项目中的目标图形进行绘制的绘制请求后，由服务器解析绘制请求，执行与绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集，然后再发送终端设备执行，完成目标图形的绘制。通过该技术方案，由于基于WebGL的图形绘制规则指令集是在服务器端形成的，服务器具有较强的运算能力，避免了终端设备的超负荷运行，减少其发热量，有利于提高用户体验和图形绘制效率。此外，由于在服务器上形成图形绘制规则指令，终端设备底层的C++引擎框架仅负责“无差别”的执行，平滑了不同终端设备的差异性，有利于JS项目在各种终端设备上的推广应用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为Web引擎端与运行器的框架结构示意图；

图2为本申请基于WebGL的图形绘制方法实施例的流程示意图；

图3为本申请基于WebGL的图形绘制方法的一个实例的信令交互图；

图4为本申请基于WebGL的图形绘制装置实施例的结构示意图；

图5为本申请另一个基于WebGL的图形绘制装置实施例的结构示意图；

图6为本申请基于WebGL的图形绘制系统实施例的结构示意图。

具体实施方式

在对本申请的各种实施例进行充分介绍之前，为便于理解，先对一些基本背景进行介绍。随着计算机技术的发展，人们对计算机信息处理的响应速度要求越来越高，尤其在一些实时应用场景之中，更是如此。比如，常见的网络对战型的实时性网络游戏，这些游戏通常涉及大量目标对象的动作、场景、角色、能力值、武器装备等的迅速变换，为更好呈现视觉效果，需要在终端设备上进行“任务艰巨”的图形绘制，图形绘制的速度成为这类软件吸引用户量的关键瓶颈。HTML5协议在网络展现上的广泛、深入的发展，对网络Web画面的显现提出了更高的要求，早期，人们通过canvas(画布)提供的标准绘图API实现丰富画面的展现。但是，这种方式的效果有限，后续逐步出现了WebGL(英文全称：Web Graphics Library)接口协议，该接口协议能够对显卡GPU进行直接控制，为HTML5 Canvas提供硬件加速渲染，大大提高了2D或3D的显示效率和显示效果。

WebGL接口与HTML5协议类似，在项目应用层上，使用JavaScript语言(以下简称JS语言)开发。在将终端设备的Web引擎端(从服务器上下载的JS项目所在处)将JS项目导入到运行器中运行时，将由运行器中的JS解析器进行解析，然后将解析后的指令按照执行顺序以压栈方式推送给C++引擎框架中执行。如前所述，这种作业模式使JS项目运行效率仍然较低，终端设备的发热量较高，此外，其兼容性也不强，制约了JS项目在不同终端设备上的推广应用。

为了解决上述问题，本申请实施例提供一种基于WebGL的图形绘制方法，参见图2，该图示出的实施例方法包括：S201：服务器接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；S202：服务器解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；S203：服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。为了更好理解该技术方案，在前述背景介绍的基础上，对该方案中的一些重要信息进行说明：

上述技术方案中各步骤涉及的执行主体为“服务器”，而在背景技术部分提到了终端设备以及在终端设备上的运行器，这里做一初步介绍，以体现出这些概念之间的异同。参见图1所示，在一般认识中，运行JS项目是在终端设备本地进行，本地的终端设备包括Web引擎端和运行器两大部分，对于运行器而言，通常又包含三部分：一是JS解析引擎部分，比如，具有该功能的V8、JSC等。从Web引擎端获得的代码尽管包含WebGL接口的一些内容，但仍然是JS代码，需要通过该JS解析引擎解析、识别，转换成运行器其他部分可运行的目标代码；二是C++引擎框架部分，该部分是运行器的“主梁”，经过JS解析引擎解析后的代码，将由该部分来完成大量的实质运算处理工作，由于采用较为底层的C++语言开发，其运行效率较高；三是渲染绘制部分，比如OpenGLES，通过C++代码调用OpenGLES函数完成图形绘制以及绘制结果提交。在本申请实施例中，由于已将一般认识中的“运行器”的部分职能创造性地移交到“服务器”上进行，因而，在本申请的实施例中如果提到“运行器”的概念，需要注意不能简单地将该运行器视为与现有技术相同的运行器，准确地说，本实施例中的运行器是进行改造后的运行器，是和服务器共同作用完成本申请发明目的的新的运行器。当然，对于是否一定称呼其为“运行器”，则是开放性的，实际上，在具备上述能力的情况下，“运行器”之名对其并不构成理解和运用上的限制。

通过将传统运行器进行改造，以得到本申请的技术方案，实际上搭建了一个全新的平台模式(可以称为服务器模式)，在该模式中，终端设备通过网络向服务器发起图形绘制请求，服务器在接收到这个请求后，对其进行解析，确定该请求指明的JS项目或JS项目中的代码段，然后执行这些项目代码，进而形成基于WebGL的图形绘制规则指令集。“基于WebGL”表明了图形绘制规则指令与WebGL之间的关系，即可以是形成的基于WebGL协议的标准指令，也可以是由用户或某个终端根据WebGL协议的标准指令设定的扩展指令。这里提到了绘制请求与JS项目代码的“对应”关系，实际上，由于在本申请实施例的模式下，JS项目是放在服务器侧的，服务器侧可以包含无数多个JS项目，终端设备要运行某个JS项目，那么应当告知服务器该JS项目(整体或局部)的地址，从而服务器能够找到该项目进行执行后续操作。从这个角度，可以将“对应”关系按照不同的阶段和场景来理解：对于初始启动项目阶段，该绘制请求中至少应当包含整体JS项目在服务器上的URL地址，这样，“执行与绘制请求对应的JS项目代码”实际上就是找到该URL地址对应的JS项目代码并执行；对于项目运行阶段，用户在终端设备上可能会在该JS项目对应的应用客户端进行某些操作，然后将这些操作结果信息通过该绘制请求发送到服务器侧，这样，“执行与绘制请求对应的JS项目代码”实际上就是执行能够响应用户操作结果信息的那段JS项目代码。当然，这种划分仅仅是一种理想的状态，实际运行中即便启动项目之后，可能面临“挂机”，可能不需要接收用户操作结果信息仍需要运行的JS项目代码段，因而，上述的两种情形可能是混合型的。总而言之，服务器形成图形绘制规则指令集，是响应绘制请求的结果，而绘制请求中的信息告知或触发了服务器应当如何去形成图形绘制规则指令集。

这里还需要说明的是，以服务器作为主体可以描述本申请的技术方案，反过来，从终端设备的角度同样可以较好地描述本申请的技术方案，即终端设备通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；终端设备接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；然后，终端设备执行所述指令流，以实现目标图形的绘制。

上述技术方案中提及图形绘制之“图形”的用语，在本实施例中，应当朝着符合行业习惯的更为广泛的角度去理解其含义。通常而言，“图形”可能限于一些几何图形，但实际上，在本实施例中不仅可以包含常规图形、图像等，比如，绘制一个图形，可以是在画布上绘制一个三角形、四边性等，而且还可以是对一个已完成的某个图形进行填色、遮盖等操作，比如，对一个已在某个时刻绘制完成的三角形进行填色，这种对三角形填色的过程仍可以独立称为图形绘制。在另一些实施例中，甚至还可以包括对一些非图形进行的处理。比如，在一张画布上布置无数离散的点，虽然其最终可能并不构成某个规范的图形，但该过程仍可称为图形绘制。也就是说，本申请实施例中的图形绘制可能包括一个具体的图形绘制过程，也可能是对已有图形或者非图形进行一定的操作。总而言之，图形绘制过程是对将要显示在画面中目标对象或与显示在画面中的对象关联的目标对象进行某个操作的过程。

上述技术方案中提及“图形绘制规则指令”的用语，这里没有称为“图形绘制指令”，主要原因在于本实施例中可以是由JS项目“制定规则”，而运行器端具体“实现规则(运行规则)”，进而达到JS代码层面少运算，甚至不运算，而将大量的底层运算工作交由运行器来完成，从而最终从运行器运行的角度提高图形绘制的性能。换句话说，图形绘制规则指令可以是不同于常规图形绘制指令的一条特殊“指令”，它至少负责告诉运行器应当“怎么干”，而不是越俎代庖式地自己“亲自上”。具体而言，在一条图形绘制规则指令中，指定了该指令确定的运算规则以及运算涉及的数据，前者在随后实施例中称为操作类型，后者称为操作对象，当运行器获得这些信息后，将按照操作类型的要求，对操作对象进行操作。举例说明如下：

setGlobalValue(globalValueID，data，operateType)

在该条指令中，参数“operateType”指明本指令将进行的操作类型，比如，可以是数据之间的加、减、赋值等操作，参数“globalValueID”、“data”是操作对象，“globalValueID”是以数据索引的形式指明的操作对象(后续还将详细叙述)，“data”则可以是该指令明确指明的操作数据本身。在这条指令中，指明了要按照“operateType”指明的操作类型对“globalValueID”和“data”进行操作，即为一种图形绘制规则指令，而不是函数本身(例如setGlobalValue)即是操作类型。

尽管上述已对“图形绘制规则指令”做文字和举例解释，但由此就将“图形绘制规则指令”理解成不可能为一条具体的图形绘制指令，则亦为错误。也就是说，某些情况下，图形绘制规则指令可以直接体现为一条具体的图形绘制指令，即在本申请中使用的术语概念中，图形绘制规则指令既包含以指定规则的形式存在的“图形绘制规则指令”，也包含直接为图形绘制指令形式的图形绘制指令，因而需要结合具体的应用场景来考虑。比如，对某个数据区内的数据执行清除操作，该图形绘制规则指令可以直接表现为一条清除指令。由此，在理解“图形绘制规则指令”的概念时，重点不在于该规则指令体现为一条规则指令，还是一条具体指令，而在于体现出制定规则与实施规则相分离的一种可能性。

还需要说明的是，在本实施例中，基于描述需要，在某些地方可能直接使用“图形绘制规则指令”，而在另一些地方，则使用“图形绘制规则指令及作为其参数的预定操作类型和操作对象”，即该概念有时是指代包含其参数在内的整体，有时是指代不包含其参数、仅具有规则部分的局部，实际应用过程中涉及到该概念理解时，不可不结合上下文进行全面的理解。

上述对图形绘制规则指令介绍清楚后，与之关联的是“图形绘制规则指令集”的概念。下面针对该概念，重点叙述如下两个方面：一是图形绘制规则指令集的内容；二是图形绘制规则指令集的形式。

就图形绘制规则指令集的内容而言，图形绘制规则指令集是由图形绘制规则指令组成，且通常意味着至少具有两条指令。在后续还会提到，一种实施例中，这些指令可以划分为两种：一种是对寄存器进行操作的指令；一种是不对寄存器进行操作的指令。按照这种以“寄存器”为标准对指令进行的分类，将产生出三种内容的“图形绘制规则指令集”：一是指令集内全部均为对寄存器进行操作的指令；二是指令集内全部均为非对寄存器进行操作的指令；三是指令集内既包含对寄存器进行操作的指令，又包含非对寄存器进行操作的指令。本申请重点针对第一类和第三类，由于这两类指令集中至少包含一条对寄存器进行操作的指令，使得本申请的技术效果得以“游刃有余”的展现(后续将详叙)。

就图形绘制规则指令集的形式而言，图形绘制规则指令集内可以仅仅是“干巴巴”的各条指令本身，也可以是包含各条指令以及各条指令对应的参数在内的指令。在前者的情况下，可能的一种情形是某些指令本身就没有操作对象或操作类型，仅仅是适应当前执行的需要插入的一条非功能性指令；另外的一种可能是将指令对应的参数(比如操作对象或操作类型)放在指令集之外，但包含发送给终端设备的指令之中。也就是说，基于图形绘制规则指令的不同形态及对图形绘制规则指令参数的不同处置方式，图形绘制规则指令集的存在形式可以是仅仅包含图形绘制指令本身的真正的“指令”集(第一种存在形式)，也可以是包含有图形绘制规则指令以及该指令对应的参数的完整型的“指令”集(第二种存在形式)。当然，还可能在一个指令集中，既包含第一种存在形式，也包含第二种存在形式，这取决于预先的设置，只要不妨碍后续运行器依据图形绘制规则指令集实现目标图形的绘制即可。

在叙述图形绘制规则指令集概念过程中，如前所述，涉及到“寄存器”，这里对寄存器做些介绍。本申请实施例对寄存器进行操作，使得寄存器成为操作对象，寄存器内存储操作数据，通过对寄存器进行操作实现对寄存器内的数据的操作。寄存器在本申请中是内存中存在的临时存储区域，这里的“临时”是相对于内存本身的存在时长而言的，在一个应用程序(或程序代码段)在运行时，计算设备通常需要开辟内存区域供存储数据和执行指令，应用程序运行完毕后(比如，用户关闭或退出应用程序)，该段内存将被释放(又新的应用程序或代码段使用)，而在内存被占用的整个期间，其上的数据始终都存在的存储区域，可以称为一种“永久”性存储区域，比如，根据需要设置的全局数据区。本申请的寄存器则表明其上存储的数据随时可能被擦除、被重新，从而不能永久性存在，因而是一种临时存储区域。对于在一个技术方案实施过程中，需要的寄存器数量，可多可少，取决于运行相应的程序代码和实现相应的功能本身的需要而定，预先设定的寄存器数量过多，可能带来浪费，预先设定的寄存器数量过少，则可能“才不尽用”，不能充分发挥本申请机制的最佳技术效果。

在上述技术方案中，提及终端设备根据指令流形式的图形绘制规则指令集对目标图形进行绘制。这里需要说明的是，终端设备完成对操作对象的操作并不一定就意味着目标图形绘制完成。实际上，终端设备对操作对象进行操作在大多数情况下，仅能认为是完成其较为核心部分的内容，除此之外，还可能具有一些其他操作，比如，由OpenGLES函数完成与GPU的对接、渲染等(参见图1所示中所示的“OpenGLES函数”部分)。但是，本实施例的重点在于突出终端设备上的新运行器相对于现有技术的核心区别，对其他操作进行简略甚至省略介绍，本领域技术人员在阅读本实施例的该步骤时，不可不细查也。

通过上述对技术方案的说明，应能排除对本实施例的理解偏差。本实施例相对于现有技术是一个突破性的发明，其技术效果呈现出如下显著特点：

一是充分利用显卡硬件，实现绘制显示加速。该实施例针对的对象是由JS代码调用WebGL接口形成的项目，由于WebGL是在OpenGLES基础上开发，可以直接操作GPU指令，从而通过显卡实现硬件加速，可以大大提高图形绘制的效率和显示效果。

二是贯彻“WebGL+”理念，成功模拟canvas。在运行器的C++引擎框架内运行的项目不再是通过JS语言调用的canvas接口，而是变更为JS语言调用WebGL接口以及WebGL1扩展函数接口，WebGL的底层性与运行器内的C++引擎框架契合，加快了运行效率。

三是可以实现服务器端与终端设备端的“优势互补”，整体性能得以显著提升。一方面，由于接收的绘制请求后，并非由终端设备端直接响应该请求，使得大量运算处理工作由终端设备端转移到服务器上，由此充分利用了服务器的“运算优势”。另一方面，终端设备端不再背负过多计算任务，在上层指明运算规则即可，不会导致大量热量产生，抹平了不同终端设备运行JS项目带来的个体差异，从而增加了终端设备端的灵活性和扩展性，充分发挥了终端设备端面向不同引擎商的“包容优势”。基于服务器、终端设备端“分工明确”，相互“取长补短”，大大提升了基于WebGL的图形绘制性能。

在上述实施例中，服务器接收来自终端设备通过网络发送的图形绘制请求，在该请求中，如前所述，通常包含终端设备的用户对JS项目对应的应用(客户端)进行操作的操作结果信息。参见图3所示，在终端设备的用户启动应用后，用户对应用会进行操作，该操作形成的操作结果信息将发送到服务器，以便服务器根据绘制请求中的操作结果信息，来形成基于WebGL的图形绘制规则指令集。这里的操作结果信息可以是对重力感应器的操作结果信息、触摸(TOUCH)事件、用户账户信息、用户状态信息等。这里的操作在一些情况下可能是直接的操作，比如，在JS项目对应的应用客户端上点击某个按钮，设置某些参数等，在另一些情况下，也可能是间接的操作，比如，用户对整个终端设备进行摇晃，导致重力感应器捕捉到不同的姿态信息，这也视为用户操作的结果。

在前述实施例中提到终端设备需要通过网络向服务器发送图形绘制请求，同时，服务器在解析绘制请求形成图形绘制规则指令集后需要以指令流的形式通过网络发送给终端设备。由于需要经过网络发送、接收数据，因而通常情况下，数据传输的速度对目标图形的绘制快慢将产生较大的影响。本申请实施例由于将运算过程由终端设备移到服务器来完成，虽然借助了服务器的运算优势，有利于提高图形绘制的效率，但在图形绘制过程中，就用户的体验而言，不仅需要有较强的运算和较快的运算速度，同时还应当有较快的传输速度。为此，在另一些实施例中，对网络的传输速度(即数据发送、接收的时长)可能具有一些要求，比如，要求终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求的时长，小于等于某个预定时长，以及要求服务器通过网络将图形绘制规则指令以指令流形式发送给终端设备的时长，小于等于另一个预定时长。而这两个时长的长短，可以进行配置，进行配置的原则可以根据终端设备对JS项目的运行要求来确定。假如该项目是一个对实时性要求较高的网络游戏，通常其用户对时间(即操作后的反馈速度)有较高的期望，这种情况下，则应当要求网络速度足够快，将预定时长设定得更为短暂。如果该项目的用户对时间不是特别敏感，而更关注画面的清晰度，则可以要求网络速度不是特别的慢即可。当然，随着通信技术的发展，不可否认的是，网络速度越来越快，这种情形下，比如，可以要求终端设备和服务器所处的网络为5G网络，而5G网络的传输速度通常高于传统的2G、3G、4G等网络。当然，在5G网络环境下，由于各种因素的影响，可能并不必然能有较快的速度，但为实施本申请的技术方案，可以要求在本技术方案实施过程中，网络传输速度大于或者保持在5G网络的平均速度上。从本申请技术方案的效果的角度来讲，本申请要求的网络速度越快越好，这样既利用了服务器的强大运算能力，也没有影响到JS项目对用户的反馈速度，从而大大提高用户体验。

在本申请的一个实施例中，图形绘制规则指令集至少包含一条对寄存器进行操作的指令。如前所述，这样将会使得图形绘制规则指令集被划分为三大类：一类是全部包含对寄存器进行操作的指令的指令集；一类是不包含对寄存器进行操作的指令集；第三类是混合有上述两种指令的指令集。实际上，通过引入寄存器的概念，至少可以取得如下的技术效果：一是可以支持判断型语句，提高代码重用性。由于图形规则指令集中包含对寄存器操作的指令，该类指令可以支持判断语句，在汇编语言级别上对寄存器进行操作，使得该指令可以直接通过压栈方式(即指令流的形式)推送给运行器的C++框架部分执行，在具体执行时，根据该对寄存器的操作决定是否进行语句的跳转，从而不用针对判断型语句的分支分别进行压栈，大大提高了代码重用性，有利于提高图形绘制的效率。二是可以支持更复杂化的场景应用。现有技术中由于执行代码的固定模式，缺乏灵活性，而在本申请实施例中，由于存在对寄存器进行操作的指令，寄存器作为临时数据存储地，可以存储不同数据计算过程中的中间数据，可以同时利用多个寄存器对多个数据进行操作，因而面对复杂化的应用场景时，灵活性更强，适应能力更突出。这些技术效果从另一方面也增强了终端设备(运行器)的扩展性。

下面在此基础上，从两个大的方向对进一步的优化技术方案进行说明，即当图形绘制规则指令为对寄存器进行操作的指令时的情形，以及当图形绘制规则指令为对寄存器进行操作的指令以外的指令时的情形，如下先从后一个方向进行描述。

在前述实施例中，当图形绘制规则指令为对寄存器进行操作的指令以外的指令时，尽管可以将操作对象直接体现在图形绘制请求之中，但是，这样将使图形绘制请求“臃肿”，尤其在操作对象体现为“量大而结构复杂”的数据时，更为“不堪其重负”，而且，当需要修改图形绘制规则指令时，又需要重新指定操作对象，给系统增加无谓的开销。为此，可以采取一种图形绘制规则指令与其操作对象分离的机制，即在图形绘制请求中包含操作对象的索引，而将索引对应的数据在运行器中临时或长久开辟的数据存储区中进行存储，这样在改变(增加或调整)图形绘制规则指令时，只要操作对象的索引不发生变化，该指令便可不变化，而仅需要修改数据存储区的数据即可。具体做法是：在图形绘制请求中指定操作对象的索引，运行器根据该操作对象索引从数据区中获取其对应的具体操作数据，然后由运行器根据预定的操作类型对该操作数据进行操作，进而完成图形绘制。举如下实例说明之：

假设图形绘制请求中包含如下内容：

SetValueByShareData(offset，operateType)

该内容中“SetValueByShareData”为图形绘制规则指令，“offset”、“operateType”为图形绘制规则指令的参数，前者指明待操作对象在数据区中的位置，后者指明针对该操作对象要进行何种类型的操作。这种情况下，如果offset＝10，operateType为擦除操作，则运行器在运行该规则指令时，先根据offset从数据区中获取偏离值为10位置上对应的数据作为操作对象，然后对该数据执行擦除操作。通过这种数据与指令的分离机制，可以提高操作的便捷性，为进行其他的进一步改进提供了技术保障。

在前述实现图形绘制规则指令与图形绘制规则指令的操作对象的分离(指令与数据分离)机制情景下，维护数据区内的数据便变得至关重要。根据实际情况和不同的划分标准，数据区可以划分为不同的类型。比如，可以划分为全局数据区和局部数据区，前者用于存储带有全局性的数据或者存储中间结果，后者用于存储带有局部性质的数据。当然，在实际应用过程中，这两个数据区可以在物理上为相邻的存储位置，也可以为隔着“千山万水”的不同物理存储位置。无论是全局数据区，还是局部数据区，其当中的数据均可在Web引擎端进行配置，比如在初始化时进行定义，然后在接受到图形绘制请求时或者之前，将这些配置好的数据同步到运行器能够访问的数据区中。比如，可以按照如下的方式配置数据区内的全局数据：

varvalueID＝GL.addValueDefine(modifyType，type，size，defaultData)

定义alpha型数据：type＝float，size＝1，defaultData＝[1]

定义matrix型数据：type＝float，size＝6，defaultData＝[1，0，0，1，0，0]

既然在某些情况下存在全局数据区和局部数据区之别，那么便可能存在只针对全局数据区或局部数据区内数据进行的操作，也可能存在一部分数据来自全局数据区，另一部分数据来自局部数据区，将两者进行某种操作的情况。也就是说，可以仅仅针对同类型的数据区内的数据进行操作，也可以在不同性质的数据区内进行数据操作，比如，图形绘制中涉及到的矩阵计算、顶点计算等情形，在需要对多个数据进行操作时，图形绘制请求中包含的操作对象(操作对象索引)则可能为多个。下面以对全局数据区内的一个数据和局部数据区内的一个数据进行矩阵运算为例进行说明：

图形绘制请求中包含如下内容：

setValueByShareData(id，offset，operateType)

该指令内容的id代表全局数据区的全局索引，假设其值为2，offset代表局部数据区内的局部索引，假设其值为4，如果当前预定的操作类型为矩阵运算，则运行器会首先根据全局数据区的全局索引id指明的位置，从全局数据区id＝2的位置获取第一操作数据，根据局部数据区的局部索引offset指明的位置，从局部数据区offset＝4的位置获取第二操作数据，然后按照operateType指明的操作类型，对第一操作数据和第二操作数据进行矩阵运算。需要强调的是，这些计算在运行器内完成，而运行器包含C++引擎框架，计算效率比现有技术中在Web引擎端高很多。在实际应用过程中，图形绘制中涉及大量的矩阵运算，通过在运行器内计算而得以大大节约处理资源。

实际上，除了矩阵运算外，图形绘制过程中涉及的操作类型还包括常规的加、减、乘、除以及顶点变形等运算类型。比如，对于图形绘制中的大量的顶点数据，可以采取上述运算中的一种来完成运算。举例如下：

modifyMesh(valueID，vdoPosID，operatorType)

该指令内容表示使用全局数据区中valueID指明的某个数据修改顶点缓冲数据区中vdoPosID指明的显卡顶点缓冲区内的某个数据，按照operatorType指定操作类型进行计算。

假设使用全局数据区中valueID＝2对应的数据，去修改顶点缓冲数据区中的vdoPosID＝0(顶点的x、y坐标)对应的数据，操作方式是矩阵变形顶点数据。该运算在运行器的C++中的代码中运算，大为提高效率。

下面从图形绘制规则指令为对寄存器进行操作的指令时的情形进行描述优化方案。与前述的道理类似，在图形绘制规则指令的参数中，作为操作对象的寄存器，通常是以寄存器索引的形式存在的，即在对数据进行操作时，图形绘制规则指令通过寄存器索引(比如，regID)指明了对哪个寄存器进行操作，只要寄存器内存储了数据，便可能完成相应的操作。寄存器内的数据来源可以包括如下两种来源：一是在执行图形绘制规则指令时，通过预定的函数将事先预定的数据写入到该寄存器中，使得寄存器内具有了相应的数据，进而可完成相应的数据操作，当然，从时间的角度考虑，也可以是在执行图形绘制规则指令之前即已完成寄存器内的数据写入操作，在指明了操作的寄存器索引号后直接对其操作即可。二是在执行图形绘制规则指令时，在该指令中还指明了操作对象索引，那么可以依据该操作对象索引从数据区中先获取该操作对象索引对应的操作数据，然后将该数据写入到对应的寄存器内。当寄存器内或者采取第一种方式或者采取第二种方式顺利填入操作数据后，运行器便可根据图形绘制规则指令按照预定的操作类型对寄存器内的操作数据进行操作，以完成对目标图像的绘制工作。

下面以两种具体的预定操作类型为例，说明对寄存器的操作。

(1)对于预定操作类型为判断型操作的情况。

所谓判断型操作即是条件型语句，判断某个条件是否满足，当满足时，执行某个判断分支；当不满足时，执行另一个判断分支，具体可以体现为IF语句、WHILE语句等。比如，为了实现语句跳转，可以通过判断寄存器内的数据是否达到预定条件，如果达到，就跳转到某条图形绘制规则指令(具体实现时，可以是直接指明跳转的目标图形绘制规则指令，从而直接跳转到该指令执行，也可以是仅指明需要跳转的指令条数，跳转后到达的指令即为目标指令)，如果未达到，则按照原来顺序执行。如下面的实例，通过判断寄存器内数据的情况，执行语句跳转：

loadInt(dataID，offset，reg[0])；//设置值到寄存器第0个上

ifE0(regID，skipStatementN)；//如果reg值＝＝0，则跳过语句执行

ifNE0(regID，skipStatementN)；//如果reg值！＝0，则跳过语句执行

ifGE0(regID，skipStatementN)；//如果reg值＞＝0，则跳过语句执行

ifG0(regID，skipStatementN)；//如果reg值＞0，则跳过语句执行

ifL0(regID，skipStatementN)；//如果reg值＜0，则跳过语句执行

ifLE0(regID，skipStatementN)；//如果reg值＜＝0，则跳过语句执行

循环语句的情形是判断型语句的复杂化，道理相同，此处不再繁复叙述。

(2)对于预定操作是运算型操作的情况。

所谓运算型操作即是对寄存器内的数据进行加、减、乘、除、矩阵等运算操作，具体可以是对一个寄存器内的数据进行操作(比如，乘方、自增、自减等)，也可以对多个寄存器内的数据进行操作，还可以对寄存器内数据和操作对象索引指明的存储在数据区内的数据直接进行操作。当对多个寄存器进行操作时，可先将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内，或者，在运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作之前，将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内。然后对第一寄存器和第二寄存器内的操作数据进行运算操作。如下面的实例，先通过函数对寄存器进行数据填充，然后按照预定操作类型对寄存器内的数据进行操作。下面的实例充分演示了上述内容。

function set XXX()

{

//第一个参数dataID，offset值，放入寄存器索引对应的寄存器中；

loadData(dataID，offset，reg[0])；

loadData(dataID，offset，reg[1])；

loadData(dataID，offset，reg[2])；

loadData(dataID，offset，reg[3])；

//对寄存器索引号为0和3的寄存器进行操作，并将操作后的值存储到寄存器索引号为2的寄存器中，type为具体的预定运算操作类型；

operate(2，0，3，type)；

operate(1，0，3，type)；

}

在介绍完两个大的方向后，下面对无论图形绘制规则指令是操作寄存器的指令，还是不操作寄存器的指令，都可能共同存在的优化技术方案。

优化方向之一：用图形绘制规则指令索引作为定位图形绘制规则指令。与前述讨论操作对象类似的道理，在解析图形绘制请求并执行JS项目代码后形成的图形绘制规则指令中，可以包含图形绘制规则指令本身，也可以包含图形绘制规则指令的索引，这样终端设备或者服务器便可以根所述图形绘制规则指令索引，确定与该图形绘制规则指令索引对应的图形绘制规则指令集，具体而言：

终端设备(运行器)根据图形绘制规则指令索引，从存储设备中查找与图形绘制规则指令索引对应的指令集，所述存储设备中存储有不同的图形绘制规则指令索引以及与不同的图形绘制规则指令索引对应的指令集。需要说明的是，这里的存储设备可以位于服务器上，也可以位于终端设备侧上，如果是位于终端设备侧上，则在终端设备接收到服务器发送的指令流后，解析出指令流后从终端设备的存储设备上根据所述图形绘制规则指令索引查找对应的指令集。

在本申请实施例中，为了便于对不同的目标图形进行绘制，可以按照上述记载的方法确定对不同的目标图形进行绘制的多个规则指令集，并将该多个规则指令集与图形绘制规则指令索引对应存储至存储设备中，这样，在绘制不同的目标图形时，可以从所述存储设备中查找得到与不同的图形绘制规则指令索引对应的指令集。

优化方向之二：在本实施例中，针对一个指令集而言，所述指令集可以对应一个数据区，所述数据区与所述指令集结合可以用于绘制得到一个目标图形；此外，所述指令集也可以对应多个数据区，每一个所述数据区与所述指令集相结合后，可以用于绘制得到不同的目标图形，即多个不同的目标图形可以共同使用一个指令集进行目标图形的绘制，这样，由于多个目标图形可以根据同一个指令集绘制得到，因此，可以有效减少存储的指令集的个数，从而有效减少指令集对存储空间的占用。

例如，指令集A可以对应数据区1和数据区2，根据指令集A和数据区1中的操作对象数据，可以绘制得到目标图形A1，根据指令集A和数据区2中的操作对象数据，可以绘制得到目标图形A2。由于目标图形A1和A2均可以根据指令集A绘制得到，因此，可以减少指令集的个数，从而减少指令集占用的存储空间。

上述介绍内容着重从图形绘制方法的角度进行说明，实际上，本申请实施例还提供了相应的装置实施例。图4为本申请的一个实施例图形绘制装置的结构示意图。该主干枝位于服务器侧，包括：请求接收单元41、解析执行单元42以及指令发送单元43，其中：

请求接收单元41，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元42，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元43，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。

上述装置能够取得与前述方法实施例同样的技术效果，为避免重复，这里不再赘言。

可选地，终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求，包括所述终端设备的用户对JS项目对应的应用进行操作的操作结果信息，则：解析执行单元42，具体用于解析所述绘制请求，执行与所述操作结果信息对应的JS项目代码，形成基于WebGL的图形绘制规则指令集。这里的操作结果信息可以是如下中一种或多种：对重力感应器的操作结果信息；触摸(TOUCH)事件信息；用户账号信息；用户状态信息。

在上述装置实施例中，所述终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求的时长，小于等于第一预定时长；所述服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备的时长，小于等于第二预定时长。这里的第一预定时长或第二预定时长可以相同，也可以不同，需要根据实际情况确定。

参见图5，与上述位于服务器侧的装置对应的，本申请实施例还可以在终端设备侧部署另一个装置，该装置包括请求发送单51、指令接收单元52和指令执行单元53，其中：

请求发送单元51，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元52，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元53，用于执行所述指令流，以实现目标图形的绘制。

上述位于服务器侧和终端侧的装置在某些情况下可以实施为一个系统，这样的系统包括服务和终端设备，其中：

服务器包括请求接收单元、解析执行单元和指令发送单元，其中：

请求接收单元，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制；

终端设备包括：请求发送单元、指令接收单元和指令执行单元，其中：

请求发送单元，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元，用于执行所述指令流，以实现目标图形的绘制。

图6为本申请基于WebGL的图形绘制另一个系统实施例的结构示意图，所述系统60中包含存储器61、处理器62及存储在所述存储器61上并可在所述处理器62上运行的计算机程序，所述计算机程序被所述处理器62执行时实现上述记载的图形绘制方法的步骤。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述记载的图形绘制方法的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (17)

1.一种基于WebGL的图形绘制方法，其特征在于，包括：

服务器接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

所述服务器解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

所述服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。

2.根据权利要求1所述的方法，其特征在于，所述终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求，包括所述终端设备的用户对JS项目对应的应用进行操作的操作结果信息，则所述服务器解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集，包括：

所述服务器解析所述绘制请求，执行与所述操作结果信息对应的JS项目代码，形成基于WebGL的图形绘制规则指令集。

3.根据权利要求2所述的方法，其特征在于，所述终端设备的用户对JS项目对应的应用进行操作的操作结果信息，包括如下一项或多项信息：

对重力感应器的操作结果信息；

触摸事件信息；

用户账号信息；

用户状态信息。

4.根据权利要求1所述的方法，其特征在于，所述终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求的时长，小于等于第一预定时长；所述服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备的时长，小于等于第二预定时长。

5.根据权利要求4所述的方法，其特征在于，所述第一预定时长和/或第二预定时长根据所述终端设备的用户对所述图形绘制的时长的要求确定。

6.根据权利要求1至5中任何一项所述的方法，其特征在于，所述网络为5G网络，基于所述第一预定时长、第二预定时长确定的网络传输速度，大于等于5G网络的平均速度。

7.一种基于WebGL的图形绘制方法，其特征在于，包括：

终端设备通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

所述终端设备接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

所述终端设备执行所述指令流，以实现目标图形的绘制。

8.根据权利要求7所述的方法，其特征在于，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域。

9.根据权利要求8所述的方法，其特征在于，所述图形绘制规则指令集包括所述图形绘制规则指令，以及作为所述图形绘制规则指令的参数的预定操作类型和操作对象；

所述终端设备执行所述指令流，以实现目标图形绘制，包括：

所述终端设备根据所述指令流中的指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

10.根据权利要求9所述的方法，其特征在于，当所述图形绘制规则指令为对寄存器进行操作的指令时，

所述操作对象包括操作对象索引和寄存器索引，则终端设备根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

所述终端设备根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据，并写入到所述寄存器索引对应的寄存器内；

所述终端设备根据所述图形绘制规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作；

或者，所述操作对象包括寄存器索引，则所述终端设备根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

所述终端设备将预定数据写入所述寄存器索引对应的寄存器内，或者，在所述终端设备根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作之前，将预定数据写入所述寄存器索引对应的寄存器内；

所述终端设备根据所述图形绘制规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作。

11.一种基于WebGL的图形绘制装置，所述装置位于服务器侧，其特征在于，包括请求接收单元、解析执行单元和指令发送单元，其中：

请求接收单元，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制。

12.根据权利要求11所述的装置，其特征在于，所述终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求，包括所述终端设备的用户对JS项目对应的应用进行操作的操作结果信息，则：

所述解析执行单元，具体用于解析所述绘制请求，执行与所述操作结果信息对应的JS项目代码，形成基于WebGL的图形绘制规则指令集。

13.根据权利要求11所述的装置，其特征在于，所述终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求的时长，小于等于第一预定时长；所述服务器通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备的时长，小于等于第二预定时长。

14.一种基于WebGL的图形绘制装置，所述装置位于终端设备侧，其特征在于，包括请求发送单元、指令接收单元和指令执行单元，其中：

请求发送单元，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元，用于执行所述指令流，以实现目标图形的绘制。

15.一种基于WebGL的图形绘制系统，其特征在于，所述系统包括服务器和终端设备，

所述服务器包括请求接收单元、解析执行单元和指令发送单元，其中：

请求接收单元，用于接收终端设备通过网络发送的对JS项目中的目标图形进行绘制的绘制请求；

解析执行单元，用于解析所述绘制请求，执行与所述绘制请求对应的JS项目代码，形成基于WebGL的图形绘制规则指令集；

指令发送单元，用于通过网络将所述图形绘制规则指令集以指令流形式发送给所述终端设备执行，以实现目标图形的绘制；

所述终端设备包括：请求发送单元、指令接收单元和指令执行单元，其中：

请求发送单元，用于通过网络向服务器发送对JS项目中的目标图形进行绘制的绘制请求；

指令接收单元，用于接收所述服务器通过网络以指令流形式发送的、解析所述绘制请求并执行与所述绘制请求对应的JS项目代码形成的、基于WebGL的图形绘制规则指令集；

指令执行单元，用于执行所述指令流，以实现目标图形的绘制。

16.一种基于WebGL的图形绘制系统，其特征在于，所述系统包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至10中任一项所述的方法的步骤。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至10中任一项所述的方法的步骤。