Browser engine interfacing for accelerated physics engine

A method for application interfacing a native physics engine includes embedding access to a native physics engine within a browser engine. Bindings are provided for supporting multiple application classes from the browser engine to the native physics engine and a JavaScript engine.

TECHNICAL FIELD

One or more embodiments generally relate to performance enhancement for Web gaming and physics simulation and, in particular, to a web browser interfacing for a hardware-accelerated physics engine.

BACKGROUND

Web-based technologies are a viable alternative to Java (Android) and Objective-C (iOS) for application development. There are, however, still areas where the web platform trails Android and iOS. Web platforms suffer low performance for compute and graphics intensive applications, such as gaming, physical simulation and dynamic visualization.

SUMMARY

One or more embodiments generally relate to interfacing a native physics engine. In one embodiment, access to a native physics engine is embedded within a browser engine. In one embodiment, bindings are provided for supporting a plurality of application classes from the browser engine to the native physics engine and a Javascript engine.

In one embodiment a non-transitory computer-readable medium having instructions which when executed on a computer perform a method comprising: providing bindings for supporting a plurality of application classes from a browser engine to a native physics engine and a Javascript engine.

In one embodiment, a browser engine comprises a webkit module. In one embodiment, a WebCore module uses a processor for providing bindings for supporting a plurality of application classes from the browser engine to a native physics engine and a Javascript core.

These and other aspects and advantages of one or more embodiments will become apparent from the following detailed description, which, when taken in conjunction with the drawings, illustrate by way of example the principles of the one or more embodiments.

DETAILED DESCRIPTION

One or more embodiments generally relate to interfacing a native physics engine. In one embodiment, access to a native physics engine is embedded within a browser engine. In one embodiment, bindings are provided for supporting a plurality of application classes from the browser engine to the native physics engine and a Javascript engine.

HTML5 is highly portable, familiar to an extremely large developer community, enables easy integration with web services, and is used for next generation platforms, such as Tizen, ChromeOS and Windows 8. Developers frequently cite application performance as a concern when considering web-based platforms, which is particularly true for gaming where there are both high compute and high graphics demands. Pure JavaScript implementation can be 2 to 10 times slower than “native” code.

For compute load of gaming applications, much time is spent in the “physics” code involved with object dynamics and physical simulation. One or more embodiments provide enhanced user experience for applications related to gaming, physical simulation, dynamic visual effects and animation, and physical realism in augmented reality applications by providing efficient access to JavaScript APIs, which bind to native efficient and performant implementation of 2D Physics Engine (Box2D). One or more embodiments allow users the access to efficient native implementation as JavaScript APIs for electronic devices (e.g., mobile phone device, tablet computing device, camera device, camcorder device, media device, laptop computing device, personal computing (PC) device, personal digital assistant (PDA) device, television device, etc.).

One or more embodiments provide a JavaScript interface to a native (open source) physics engine. In conjunction with WebGL, one or more embodiments provide web-based platforms for electronic devices with the compute and graphics power required for gaming, by enabling access to a native physics engine through JavaScript APIs.

FIG. 1is a schematic view of a communications system, in accordance with one embodiment. Communications system1may include a communications device that initiates an outgoing communications operation (transmitting device2) and a communications network110, which transmitting device2may use to initiate and conduct communications operations with other communications devices within communications network110. For example, communications system1may include a communication device that receives the communications operation from the transmitting device2(receiving device3). Although communications system1may include multiple transmitting devices2and receiving devices3, only one of each is shown inFIG. 1to simplify the drawing.

Any suitable circuitry, device, system or combination of these (e.g., a wireless communications infrastructure including communications towers and telecommunications servers) operative to create a communications network may be used to create communications network110. Communications network110may be capable of providing communications using any suitable communications protocol. In some embodiments, communications network110may support, for example, traditional telephone lines, cable television, Wi-Fi (e.g., an IEEE 802.11 protocol), Bluetooth®, high frequency systems (e.g., 900 MHz, 2.4 GHz, and 5.6 GHz communication systems), infrared, other relatively localized wireless communication protocol, or any combination thereof. In some embodiments, the communications network110may support protocols used by wireless and cellular phones and personal email devices (e.g., a Blackberry®). Such protocols can include, for example, GSM, GSM plus EDGE, CDMA, quadband, and other cellular protocols. In another example, a long range communications protocol can include Wi-Fi and protocols for placing or receiving calls using VOIP, LAN, WAN, or other TCP-IP based communication protocols. The transmitting device2and receiving device3, when located within communications network110, may communicate over a bidirectional communication path such as path4, or over two unidirectional communication paths. Both the transmitting device2and receiving device3may be capable of initiating a communications operation and receiving an initiated communications operation.

The transmitting device2and receiving device3may include any suitable device for sending and receiving communications operations. For example, the transmitting device2and receiving device3may include a mobile telephone devices, television systems, cameras, camcorders, a device with audio video capabilities, tablets, and any other device capable of communicating wirelessly (with or without the aid of a wireless-enabling accessory system) or via wired pathways (e.g., using traditional telephone wires). The communications operations may include any suitable form of communications, including for example, voice communications (e.g., telephone calls), data communications (e.g., e-mails, text messages, media messages), video communication, or combinations of these (e.g., video conferences).

FIG. 2shows a functional block diagram of an architecture system100that may be used for providing JavaScript bindings to a native (open source) physics engine on an electronic device120, according to an embodiment. Both the transmitting device2and receiving device3may include some or all of the features of the electronics device120. In one embodiment, the electronic device120may comprise a display121, a microphone122, an audio output123, an input mechanism124, communications circuitry125, control circuitry126, a camera module128, a web engine module135, and any other suitable components. In one embodiment, applications1-N127are provided and may be obtained from a cloud or server130, a communications network110, etc., where N is a positive integer equal to or greater than 1.

In one embodiment, all of the applications employed by the audio output123, the display121, input mechanism124, communications circuitry125, and the microphone122may be interconnected and managed by control circuitry126. In one example, a handheld music player capable of transmitting music to other tuning devices may be incorporated into the electronics device120.

In one embodiment, the audio output123may include any suitable audio component for providing audio to the user of electronics device120. For example, audio output123may include one or more speakers (e.g., mono or stereo speakers) built into the electronics device120. In some embodiments, the audio output123may include an audio component that is remotely coupled to the electronics device120. For example, the audio output123may include a headset, headphones, or earbuds that may be coupled to communications device with a wire (e.g., coupled to electronics device120with a jack) or wirelessly (e.g., Bluetooth® headphones or a Bluetooth® headset).

In one embodiment, the display121may include any suitable screen or projection system for providing a display visible to the user. For example, display121may include a screen (e.g., an LCD screen) that is incorporated in the electronics device120. As another example, display121may include a movable display or a projecting system for providing a display of content on a surface remote from electronics device120(e.g., a video projector). Display121may be operative to display content (e.g., information regarding communications operations or information regarding available media selections) under the direction of control circuitry126.

In one embodiment, input mechanism124may be any suitable mechanism or user interface for providing user inputs or instructions to electronics device120. Input mechanism124may take a variety of forms, such as a button, keypad, dial, a click wheel, or a touch screen. The input mechanism124may include a multi-touch screen.

In one embodiment, communications circuitry125may be any suitable communications circuitry operative to connect to a communications network (e.g., communications network110,FIG. 1) and to transmit communications operations and media from the electronics device120to other devices within the communications network. Communications circuitry125may be operative to interface with the communications network using any suitable communications protocol such as, for example, Wi-Fi (e.g., an IEEE 802.11 protocol), Bluetooth®, high frequency systems (e.g., 900 MHz, 2.4 GHz, and 5.6 GHz communication systems), infrared, GSM, GSM plus EDGE, CDMA, quadband, and other cellular protocols, VOIP, TCP-IP, or any other suitable protocol.

In some embodiments, communications circuitry125may be operative to create a communications network using any suitable communications protocol. For example, communications circuitry125may create a short-range communications network using a short-range communications protocol to connect to other communications devices. For example, communications circuitry125may be operative to create a local communications network using the Bluetooth® protocol to couple the electronics device120with a Bluetooth® headset.

In one embodiment, control circuitry126may be operative to control the operations and performance of the electronics device120. Control circuitry126may include, for example, a processor, a bus (e.g., for sending instructions to the other components of the electronics device120), memory, storage, or any other suitable component for controlling the operations of the electronics device120. In some embodiments, a processor may drive the display and process inputs received from the user interface. The memory and storage may include, for example, cache, Flash memory, ROM, and/or RAM. In some embodiments, memory may be specifically dedicated to storing firmware (e.g., for device applications such as an operating system, user interface functions, and processor functions). In some embodiments, memory may be operative to store information related to other devices with which the electronics device120performs communications operations (e.g., saving contact information related to communications operations or storing information related to different media types and media items selected by the user).

In one embodiment, the control circuitry126may be operative to perform the operations of one or more applications implemented on the electronics device120. Any suitable number or type of applications may be implemented. Although the following discussion will enumerate different applications, it will be understood that some or all of the applications may be combined into one or more applications. For example, the electronics device120may include an automatic speech recognition (ASR) application, a dialog application, a map application, a media application (e.g., QuickTime, MobileMusic.app, or MobileVideo.app), social networking applications (e.g., Facebook®, Twitter®, Etc.), an Internet browsing application, etc. In some embodiments, the electronics device120may include one or multiple applications operative to perform communications operations. For example, the electronics device120may include a messaging application, a mail application, a voicemail application, an instant messaging application (e.g., for chatting), a videoconferencing application, a fax application, or any other suitable application for performing any suitable communications operation.

In some embodiments, the electronics device120may include a microphone122. For example, electronics device120may include microphone122to allow the user to transmit audio (e.g., voice audio) for speech control and navigation of applications1-N127, during a communications operation or as a means of establishing a communications operation or as an alternative to using a physical user interface. The microphone122may be incorporated in the electronics device120, or may be remotely coupled to the electronics device120. For example, the microphone122may be incorporated in wired headphones, the microphone122may be incorporated in a wireless headset, the microphone122may be incorporated in a remote control device, etc.

In one embodiment, the camera module128comprises one or more camera devices that include functionality for capturing still and video images, editing functionality, communication interoperability for sending, sharing, etc. photos/videos, etc.

In one embodiment, the electronics device120may include any other component suitable for performing a communications operation. For example, the electronics device120may include a power supply, ports, or interfaces for coupling to a host device, a secondary input mechanism (e.g., an ON/OFF switch), or any other suitable component.

In one embodiment, the web engine module135provides embedded access to an efficient native physics engine into a browser engine in the electronic device120. In one embodiment, the web engine module135includes a JavaScript API implemented in a WebKit browser engine as a JavaScript binding for a 2D Physics Engine (e.g., Box2D).

FIG. 3shows a block diagram of a high level view of a system300including a web engine (or WebCore)301of the web engine module135of the electronic device120, according to an embodiment. In one embodiment, the system300comprises the web engine301including at least one Web API310and JavaScript bindings portion320, a native physics engine330(e.g., Box2D), a JavaScript engine or core340, and web applications350.

In one embodiment, the web engine301provides transparent access from web applications350to the native physics engine330functionalities and APIs through JavaScript bindings from the JavaScript bindings portion320in the browser engine301. In one embodiment, the transparent access from the web applications350to the native physics engine330provides performance gain, relative to a JavaScript-only implementation.

FIG. 4shows a block diagram of a Box2D binding architecture400, according to an embodiment. In one embodiment, the Box2D binding architecture comprises the web engine301, the JavaScript core340and a Box2D native engine450. In one embodiment, the JavaScript bindings portion320for Box2D JavaScript bindings comprises a Box2D bindings generator module410and a wrapping or glue layer420.

In one embodiment, the Box2D bindings generator module410provides Box2D binding classes and functions that may be automatically generated from Box2D Interface Definition Language (IDL) files (IDLs). In one embodiment, the wrapping layer420is mostly JavaScript engine340independent and provides a one-to-one mapping of Box2D native objects and wrapper objects for improving performance of web applications (e.g., web applications350).

In one or more embodiments, the Box2D bindings generator module410includes an IDL code generator that supports constructor-type static read-only attributes in IDL (e.g., patch up-streamed to code based on WebKit.org). In one or more embodiments, the wrapping layer420supports general Box2D 2D Physics Engine classes, their functions, attributes and enums. In one or more embodiments, the wrapping layer420preserves Box2D tree structures. In one or more embodiments, the wrapping layer420supports Callback functions, such as Listeners. In one or more embodiments, the wrapping layer420supports debug draw and supports unusual data types (e.g., void).

In one embodiment, the Box2D bindings generator module410generates the binding classes and functions for Box2D and communicates these to the wrapping layer420that provides the mapping and Box2D API calls430to the Box2D native engine450. In one embodiment, the Box2D native engine450communicates back to the wrapping layer420with Box2D callbacks440, which are mapped and communicated to the Box2D bindings generator module410. In one embodiment, the Box2D bindings generator module410communicates internal JavaScript interfaces465(e.g., invokeCallback) to the JavaScript engine340. In one embodiment, the JavaScript engine340communicates internal WebCore interfaces/function tables460to the Box2D bindings generator module410.

FIG. 5shows an example binding class diagram500, according to an embodiment. In one example embodiment, the example binding class diagram500includes binding classes supported in an example WebKit implementation. As illustrated inFIG. 5, in one example embodiment, the class tree comprises the document object module (DOM) Window (DOMWindow)510that includes a WBox2D class520having WebBox2D objects. In one example embodiment, the WBox2D class525comprises objects for a WCommon class531that includes common objects, a WCollision class532having collision objects, and a WDynamics class533having dynamics objects.

In one example embodiment, the WCommon class531includes objects, such as Wmath with Math objects, which also has a tree structure with Wmath class541and the associated objects. In one example embodiment, the WCollision class532includes objects, such as WShapes with Shape objects, which also has a tree structure with WShapes class542and the associated objects. Similarly, in one example embodiment, the WDynamics class533includes objects, such as WContacts with Contact objects, and WB2Body Constructor, which also have tree structures with WContacts class543and WB2Body class544, and the respective associated objects. As seen inFIG. 5, the tree structure of the binding class diagram500may expand outward until the classes and objects are exhausted.

In one embodiment, the IDL code generator of the Box2D bindings generator module410(FIG. 4) generates CPP/H filed based on IDL files. In one embodiment, the following is an example of IDL pseudo-code as an input for the Box2D bindings generator module410:

In one embodiment, an example of pseudo-code for a web application (e.g.,FIG. 3, web application350) comprises the following:

FIG. 6shows a functional call flow diagram600, according to an embodiment. In one embodiment, the functional flow starts from the web application350. In one example, embodiment, with reference to the pseudo-code for the web application listed above, when ‘obj1.f1’610is called, the JavaScript engine340(JavascriptCore) triggers a function call JSC::call( )620that calls into a function in the WebCore301, for example function ‘jsWB2Class1PrototypeFunctionf1’630in the auto-generated component (e.g., from the Box2D bindings generator module410) through a table (e.g., a hash table, or similar structure) where key “f1” is mapped to this function. In one example, embodiment, the function jsWB2Class1PrototypeFunctionf1630then calls the wrapper/glue layer420function ‘WB2Class1::f1’640, which further calls the native function ‘b2Class1::f1’650from the Box2D native engine450.

FIG. 7Ashows a block diagram of an architecture700for JavaScript bindings for Box2D, according to an embodiment.FIG. 7Bshows a block diagram of an example Box2DWeb architecture750. In one or more embodiments, the architecture700comprises the web application350, a web engine including browser/WebRuntime module720, WebKit710and WebCore301including (Box2D) JavaScript bindings portion320, the JavaScript engine340and the Box2D native engine450.

The Box2DWeb architecture750includes the web application350, a Box2DWeb JavaScript library module770, a browser/WebRuntime720, a WebKit710, a WebCore760and JavaScript engine340. The Box2DWeb architecture750is a JavaScript implementation of 2D Physics Engine (Box2DWeb) and provides a very inefficient architecture as compared to the one or more embodiments of the architecture700for JavaScript bindings for Box2D (Web Physics) implementation. One or more embodiments implementing the architecture700for JavaScript bindings for Box2D provides efficient access from web applications (e.g., Web application350) to the Box2D native physics engine450by implementing JavaScript bindings for a 2D Physics engine (Box2D) using JavaScript APIs.

FIG. 8shows a flowchart process800for application interfacing a native physics engine, according to an embodiment. In one embodiment, in block810of process800embeds access to a native physics engine (e.g.,FIG. 3, native physics engine330;FIG. 4, Box2D native engine450) within a browser engine (e.g.,FIG. 2, web engine module135;FIGS. 3 and 4, web engine301) of an electronic device (e.g.,FIG. 2, electronic device120). In one embodiment, in block820, bindings for supporting application classes from the browser engine to the native physics engine and a Javascript engine (e.g.,FIGS. 3 and 4, JavaScript engine340) are provided.

As is known to those skilled in the art, the aforementioned example architectures described above, according to said architectures, can be implemented in many ways, such as program instructions for execution by a processor, as software modules, microcode, as computer program product on computer readable media, as analog/logic circuits, as application specific integrated circuits, as firmware, as consumer electronic devices, AV devices, wireless/wired transmitters, wireless/wired receivers, networks, multi-media devices, etc. Further, embodiments of said Architecture can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.

One or more embodiments have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to one or more embodiments. Each block of such illustrations/diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor create means for implementing the functions/operations specified in the flowchart and/or block diagram. Each block in the flowchart/block diagrams may represent a hardware and/or software module or logic, implementing one or more embodiments. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc.

The terms “computer program medium,” “computer usable medium,” “computer readable medium”, and “computer program product,” are used to generally refer to media such as main memory, secondary memory, removable storage drive, a hard disk installed in hard disk drive. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Computer program instructions may be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

Computer program instructions representing the block diagram and/or flowcharts herein may be loaded onto a computer, programmable data processing apparatus, or processing devices to cause a series of operations performed thereon to produce a computer implemented process. Computer programs (i.e., computer control logic) are stored in main memory and/or secondary memory. Computer programs may also be received via a communications interface. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor and/or multi-core processor to perform the features of the computer system. Such computer programs represent controllers of the computer system. A computer program product comprises a tangible storage medium readable by a computer system and storing instructions for execution by the computer system for performing a method of one or more embodiments.