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

Abstract

本申请公开了一种基于WebGL的图形绘制方法、装置及系统。该方法包括：运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；运行器根据所述图形绘制规则指令集对所述目标图形进行绘制。通过该技术方案，可以解决图形绘制效率较低的问题。

Description

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

技术领域

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

背景技术

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

按照上述方式进行的图形绘制，指令集中的每条指令将按照“压栈”的顺序逐条执行，这种方式能够满足一些简单的应用场景，对于一些复杂的应用场景却“爱莫能助”。在现实应用中，指令集中的指令并非均是按序执行。比如，可能大量存在指令跳转(IF语句)的情形，即在满足预设条件时，由本条指令跳转到另一条指令执行(比如图1b中C执行后，在一定条件下执行D，在另一条件下执行F)，而不是执行紧随本条指令之后的那条指令；再比如，可能大量存在指令循环(WHILE语句)的情形，即在满足预设循环条件时，由本条指令回跳到其先前的某条指令，直至满足预设结束循环条件，才跳出循环执行随后的指令。这种具有跳转、循环等复杂应用场景下，由于“压栈”顺序固定，针对每周新的执行顺序必须重新组装、重新压栈，然后推送新的压栈的指令到C++引擎框架中执行。显然，这种方式将降低指令的重用性，不能适用复杂场景需要，浪费较多资源，影响图形绘制的效率。

发明内容

本申请实施例提供一种基于WebGL的图形绘制方法和装置，用于增强指令重用性，扩展适用场景，节约资源和提高或改善图形绘制效率。

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

运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

运行器根据所述图形绘制规则指令集对所述目标图形进行绘制。

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

接收单元，用于接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

绘制单元，用于根据所述图形绘制规则指令集对所述目标图形进行绘制。

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

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

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

本申请实施例提供的技术方案，在运行器接收的目标图形的绘制请求中其包含的基于WebGL的图形绘制规则指令集中的指令，至少包含一条对寄存器进行操作的指令，运行器根据这样的图形绘制规则指令集对目标图形进行绘制。由于寄存器处于汇编语言级别，在指令集中包含这种对寄存器进行操作的指令，可以通过其“串联”起其他指令，在JS解析器解析完后以压栈方式推送执行时，将按照对寄存器操作的结果执行本指令和指令集中的其他指令，从而有利于增强了代码的重用性，提高图形绘制的效率。

附图说明

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

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

图1b为运行器中指令压栈方式示意图；

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

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

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

具体实施方式

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

WebGL接口与HTML5协议类似，在项目应用层上，使用JavaScript语言(以下简称JS语言)开发。在将Web引擎端的JS项目导入到运行器中运行时，将由运行器中的JS解析器进行解析，然后将解析后的指令按照执行顺序以压栈方式推送给C++引擎框架中执行。这种作业模式导致以JS语言编写的判断型语句如果要得以实现，必须对判断的多个分支分别进行完整的编译，形成指令栈，从而降低了指令代码的重用性，不利于提高图形绘制的效率。而且，也不能适应一些复杂的运算场景，导致这种方式的运用受到极大限制。

为了解决上述问题，本申请实施例提供一种基于WebGL的图形绘制方法，参见图2，该图示出的实施例方法包括：S201：运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；S202：运行器根据所述图形绘制规则指令集对所述目标图形进行绘制。为了更好理解该技术方案，在前述背景介绍的基础上，对该方案中的一些重要信息进行说明：

上述技术方案中步骤S201、S202涉及的执行主体为“运行器”，运行器中通常包含三部分：一是JS解析引擎部分，比如，具有该功能的V8、JSC等。从Web引擎端获得的代码尽管包含WebGL接口的一些内容，但仍然是JS代码，需要通过该JS解析引擎解析、识别，转换成运行器其他部分可操作的目标代码；二是C++引擎框架部分，该部分是运行器的“主梁”，经过JS解析引擎解析后的代码，将由该部分来完成大量的实质运算处理工作，由于采用较为底层的C++语言开发，其运行效率较高；三是渲染绘制部分，比如OpenGLES，通过C++代码调用OpenGLES函数完成图形绘制以及绘制结果提交。虽然这里执行主体采用运行器，但是，由于本申请实施例在运行器中的执行过程与现有的运行器相比，发生了适当变化，因此，在理解该实施例中的执行主体时，不能简单地将该运行器视为与现有技术相同的运行器，准确地说，本实施例中的运行器是能够完成其随后将执行的功能的运行器(即至少能够完成步骤S201、S202)，比如，应当具备识别图形绘制指令的能力，如果是后续提及的图形绘制规则指令，则其应当具备依据图形绘制指令确定操作对象和操作类型的能力，基于获得的操作对象数据和识别出的操作类型进行操作的能力，以最终完成图形绘制的能力等等。同样地，是否一定称呼其为“运行器”，在具备上述能力的情况下，“运行器”之名对其并不构成理解和运用上的限制。

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

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

setGlobalValue(globalValueID，data，operateType)

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

尽管上述对“图形绘制规则指令”做文字和举例解释，但由此就将“图形绘制规则指令”理解成不可能为一条具体的图形绘制指令，则亦为错误。也就是说，某些情况下，图形绘制规则指令可以直接体现为一条具体的图形绘制指令，即在本申请中使用的术语概念中，图形绘制规则指令既包含以指定规则的形式存在的“图形绘制规则指令”，也包含直接为图形绘制指令形式的图形绘制指令，因而需要结合具体的应用场景来考虑。比如，对某个数据区内的数据执行清除操作，该图形绘制规则指令可以直接表现为一条清除指令。由此，在理解“图形绘制规则指令”的概念时，不在于该规则指令体现为一条规则指令，还是一条具体指令，而在于强调该指令是可以不在Web引擎端执行，而需要到运行器中执行。实际应用过程中，为了表达出这种区别，可以由Web引擎端给“图形绘制规则指令”定义出预定的标识，当Web引擎端“看到”该标识时，便知“此非分内之事”，做出“放行”之举，交由运行器处理。此外，基于WebGL的图形绘制规则指令中的“基于WebGL”，表明了图形绘制规则指令与WebGL之间的关系，即可以是形成的基于WebGL协议的标准指令，也可以是由用户或某个终端根据WebGL协议的标准指令设定的扩展指令。

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

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

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

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

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

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

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

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

二是可以实现Web引擎端与运行器端的“优势互补”，整体性能得以显著提升。一方面，由于接收的绘制请求包含的是图形绘制规则指令，而并非由Web引擎端计算后的现成结果，使得大量运算处理工作由Web引擎端转移到运行器，而运行器由C++引擎框架组成，其计算效率大大高于Web引擎端中JS代码层，由此充分利用了运行器的“运算优势”。另一方面，Web引擎端不再背负过多计算任务，在上层指明运算规则即可，从而增加了Web引擎端的灵活性和扩展性，充分发挥了Web引擎端面向不同引擎商的“包容优势”。基于运行器、Web引擎端“分工明确”，相互“取长补短”，大大提升了基于WebGL的图形绘制性能。

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

四是可以支持判断型语句，提高代码重用性。由于图形规则指令集中包含对寄存器操作的指令，该类指令可以支持判断语句，在汇编语言级别上对寄存器进行操作，使得该指令可以直接通过压栈方式推送给运行器的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引擎以及C++引擎框架之间数据共享。这样，在绘制所述目标图形时，由于图形绘制规则指令索引对应的所述指令集在所述JS引擎和C++引擎框架中数据共享，因此，JS引擎可以只进行一次函数调用，即只调用一次接口，并告知C++引擎框架执行所述指令集便可完成图形绘制。

在本申请提供的一个实施例中，如前所述，图形绘制规则指令集中可以直接包含操作对象，也可以包含操作对象的索引。在直接包含操作对象的情况下，该操作对象数据可以用于与所述指令集中包含的多条指令相结合，共同绘制得到所述目标图形，例如，所述操作对象数据可以是目标图形的位置、大小等。在根据所述指令集中包含的多条指令，对所述目标图形进行绘制时，可以根据所述指令集中包含的多条指令以及操作对象数据，对所述目标图形进行绘制。

具体地，运行器在根据所述指令集中包含的多条指令以及操作对象数据绘制所述目标图形时，JS引擎可以只调用一次接口，告知C++引擎框架可以根据所述指令集绘制所述目标图形，此时，C++引擎框架可以直接从共享的所述存储设备中调用所述指令集，并根据所述指令集中包含的多条指令以及操作对象数据完成所述目标图形的绘制。由于JS引擎只需要一次调用就可以完成一次图形绘制，因此，可以有效提高运行器的运行效率。

在本实施例中，当JS引擎需要对指令集中的操作对象数据进行修改时，由于所述存储设备中存储的指令集在JS引擎以及C++引擎框架之间数据共享，因此，JS引擎可以直接修改所述指令集中的操作对象数据，无需进行其他操作，在绘制图形时，C++引擎框架可以直接使用修改后的指令集进行图形绘制，可以在指令集修改的情况下实现高效率绘图。

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

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

基于本实施例中指令集与数据区分开存储的设计，在根据所述指令集中包含的多条指令，对所述目标图形进行绘制时，可以包括：

从所述存储设备中查找与所述指令集对应的其中一个所述数据区；

根据所述指令集中包含的操作对象索引，从查找到的所述数据区中确定与所述操作对象索引对应的操作对象数据；

根据所述操作对象数据以及所述指令集中包含的多条指令，对所述目标图形进行绘制。

具体地，运行器中的JS引擎可以根据实际绘制需求确定与所述指令集对应的一个数据区，并通过一次接口调用告知C++引擎使用所述指令集以及所述数据区进行图形绘制，此时，C++引擎框架可以根据所述指令集中包含的操作对象索引，从所述存储设备中的所述数据区中查找与所述操作对象索引对应的操作对象数据，并将该操作对象数据与所述指令集中包含的多条指令相结合，最终可以绘制得到所述目标图形。

例如，JS引擎在确定用于绘制目标图形的指令集A后，根据实际绘制需求从所述存储设备中确定与指令集A对应的数据区1后，可以将指令集A以及数据区1通过调用一次接口告知C++引擎框架，此时，C++引擎框架可以根据指令集A中包含的操作对象索引M，从数据区1中查找到与操作对象索引M对应的操作对象数据x，C++引擎框架在确定指令集A以及对应的操作对象数据x后，可以将指令集A与操作对象数据x相结合进而绘制得到所述目标图形。

上述介绍内容着重从图形绘制方法的角度进行说明，实际上，本申请实施例还提供了相应的装置实施例。图3为本申请基于WebGL的图形绘制装置实施例的结构示意图。所述图形绘制装置包括：接收单元31和绘制单元32，其中：

接收单元31，用于接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

绘制单元32，用于根据所述图形绘制规则指令集对所述目标图形进行绘制。

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

可选地，所述图形绘制请求中包含所述图形绘制规则指令以及作为所述图形绘制规则指令的参数的预定操作类型和操作对象；则：

绘制单元32，具体用于根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

可选地，当所述图形规则指令为对寄存器进行操作的指令时，则绘制单元32包括数据获取子单元321和绘制子单元322，其中：

数据获取子单元321，具体用于在所述操作对象包括操作对象索引和寄存器索引时，根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据，并写入到所述寄存器索引对应的寄存器内；在所述操作对象包括寄存器索引时，将预定数据写入所述寄存器索引对应的寄存器内；

绘制子单元322，具体用于根据所述图形绘制规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作。

进一步优选地，在预定操作类型为判断型操作，则绘制子单元322，具体用于判断所述寄存器内的操作数据是否满足预定条件；如果满足，则跳转到预设的图形规则指令执行。在预定操作类型为运算型操作，则绘制子单元322，具体用于根据所述图形规则指令对所述寄存器内的操作数据进行运算操作。

在另一个实施例中，寄存器索引包括第一寄存器索引和第二寄存器索引，则：

数据获取子单元321，具体用于将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内，或者，在运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作之前，将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内；

绘制子单元322，具体用于根据所述图形规则指令对所述第一寄存器和第二寄存器内的操作数据进行运算操作。

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

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

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

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

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

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

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

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

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

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

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

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

Claims (13)

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

运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

运行器根据所述图形绘制规则指令集对所述目标图形进行绘制；

所述图形绘制请求中包含所述图形绘制规则指令以及作为所述图形绘制规则指令的参数的预定操作类型和操作对象；所述运行器根据所述图形绘制规则指令集对所述目标图形进行绘制，具体包括：运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制；

当所述图形绘制规则指令为对寄存器进行操作的指令以外的指令时，所述操作对象为操作对象索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：运行器根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据；运行器根据所述图形绘制规则指令按照所述预定操作类型对所述操作数据进行操作。

2.根据权利要求1所述的方法，其特征在于，所述数据区包括全局数据区和局部数据区，所述操作对象索引包括全局数据区内第一操作数据的全局索引和局部数据区内第二操作数据的局部索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

运行器根据所述全局索引从全局数据区获取第一操作数据，根据所述局部索引从局部数据区内获取第二操作数据；

运行器根据所述图形绘制规则指令按照所述预定操作类型对第一操作数据和第二操作数据进行操作。

3.根据权利要求2所述的方法，其特征在于，所述全局数据区由Web引擎设置，在图形绘制之前或之时由Web引擎端同步到运行器的数据区。

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

运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

运行器根据所述图形绘制规则指令集对所述目标图形进行绘制；

所述图形绘制请求中包含所述图形绘制规则指令以及作为所述图形绘制规则指令的参数的预定操作类型和操作对象；所述运行器根据所述图形绘制规则指令集对所述目标图形进行绘制，具体包括：运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制；

当所述图形规则指令为对寄存器进行操作的指令时，

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

运行器根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据，并写入到所述寄存器索引对应的寄存器内；运行器根据所述图形规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作；

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

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

5.根据权利要求4所述的方法，其特征在于，所述预定操作类型为判断型操作，则所述运行器根据所述图形规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作，包括：

运行器判断所述寄存器内的操作数据是否满足预定条件；如果满足，则跳转到预设的图形绘制规则指令，以便运行器执行所述预设的图形绘制规则指令对目标图形进行绘制。

6.根据权利要求4所述的方法，其特征在于，所述预定操作类型为运算型操作，则所述运行器根据所述图形规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作，包括：

运行器根据所述图形规则指令对所述寄存器内的操作数据进行运算操作。

7.根据权利要求6所述的方法，其特征在于，所述寄存器索引包括第一寄存器索引和第二寄存器索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

运行器将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内，或者，在运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作之前，将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内；

运行器根据所述图形规则指令对所述第一寄存器和第二寄存器内的操作数据进行运算操作。

8.一种基于WebGL的图形绘制装置，其特征在于，包括：

接收单元，用于接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令集，所述图形绘制规则指令集至少包含一条对寄存器进行操作的指令，所述寄存器为内存中的临时存储区域；

绘制单元，用于根据所述图形绘制规则指令集对所述目标图形进行绘制；

所述图形绘制请求中包含所述图形绘制规则指令以及作为所述图形绘制规则指令的参数的预定操作类型和操作对象；则：

所述绘制单元，具体用于根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制；

当所述图形规则指令为对寄存器进行操作的指令时，所述绘制单元包括数据获取子单元和绘制子单元，其中：

所述数据获取子单元，具体用于在所述操作对象包括操作对象索引和寄存器索引时，根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据，并写入到所述寄存器索引对应的寄存器内；在所述操作对象包括寄存器索引时，将预定数据写入所述寄存器索引对应的寄存器内；

所述绘制子单元，具体用于根据所述图形绘制规则指令按照所述预定操作类型对所述寄存器内的操作数据进行操作。

9.根据权利要求8所述的装置，其特征在于，所述预定操作类型为判断型操作，则所述绘制子单元，具体用于判断所述寄存器内的操作数据是否满足预定条件；如果满足，则跳转到预设的图形规则指令执行。

10.根据权利要求8所述的装置，其特征在于，所述预定操作类型为运算型操作，则所述绘制子单元，具体用于根据所述图形规则指令对所述寄存器内的操作数据进行运算操作。

11.根据权利要求10所述的装置，其特征在于，所述寄存器索引包括第一寄存器索引和第二寄存器索引，则：

所述数据获取子单元，具体用于将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内，或者，在运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作之前，将预定的第一数据或者从数据区中获取的第一数据写入所述第一寄存器索引对应的第一寄存器内，将预定的第二数据或者从数据区中获取的第二数据写入所述第二寄存器索引对应的第二寄存器内；

所述绘制子单元，具体用于根据所述图形规则指令对所述第一寄存器和第二寄存器内的操作数据进行运算操作。

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

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