Patent Publication Number: US-10789262-B2

Title: Progressive chart rendering

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is related to, and claims benefit of and priority to, U.S. Provisional Patent Application No. 62/506,739, filed May 16, 2017, the contents of which are hereby incorporated by reference in their entirety for all purposes. 
    
    
     BACKGROUND 
     Conventional systems attempt to improve application performance by improving the efficiency with which content is generated, improving the efficiency with which the generated content is acquired and/or improving the efficiency with which acquired content is rendered on a display. Each of these efficiencies effect not only the performance of an application but also a user&#39;s perception of the application&#39;s performance. Since user satisfaction is attributable in large part to this perceived performance, other techniques for improving perceived application performance are desired. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a system architecture according to some embodiments. 
         FIG. 2  is a flow diagram of a process according to some embodiments. 
         FIG. 3  is a block diagram illustrating operation according to some embodiments. 
         FIG. 4  is a block diagram illustrating operation according to some embodiments. 
         FIG. 5  is a flow diagram of a process according to some embodiments. 
         FIG. 6  is a block diagram of a system architecture according to some embodiments. 
         FIG. 7  is a block diagram of an apparatus according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art. 
     Generally, some embodiments improve the perceived performance of a data-rendering application. According to some embodiments, and in response to a request for a data visualization, a local cached copy of the data visualization is initially rendered while active data is contemporaneously fetched in the background. The fetched active data is rendered in a hidden mode. Once fetching and rendering of the active data is complete, the rendered cached data is swapped out for the hidden rendered data. Because a data visualization (i.e., the cached copy) is rendered before the active data is fetched, a user perceives improved performance as compared to systems which render a requested chart only after the active data of the requested chart is received. 
       FIG. 1  is a block diagram of system  100  according to some embodiments. Embodiments are not limited to the  FIG. 1  system. System  100  includes data store  110 , database management system (DBMS)  120 , server  130 , and clients  140 . Server  130  may execute data visualization application  132  to provide visualizations of data stored in data store  110  according to some embodiments. Server  130  may also receive requests from client  140  and provide the data visualizations thereto in response. The data visualizations may be provided in a format which may be rendered by applications executed by client  140  (e.g., a Java Execution Engine executing within a Web Browser on client  140 ). 
     According to some embodiments, client  140  executes a Web browser to present a user interface to a user on a display of client  140 . The user enters a query into the user interface, and client  140  passes a request based on the query to server  130 . Server  130  generates an SQL script based on the request, and forwards the SQL script to DBMS  120 . DBMS  120  executes the SQL script to return a result set to server  130  based on data of data store  110 , data visualization application  132  generates a data visualization based on the result set, and the client  140  renders the data visualization. According to some embodiments, client  140  receives the result set and generates and renders a data visualization based thereon. 
     Data store  110  may comprise any data sources which are or become known, including but not limited to database views, spreadsheets, relational databases and/or OnLine Analytical Processing cubes. Data store  110  may also comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Data store  110  may comprise a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. The data of data store  110  may be distributed among several relational databases, dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources. 
     In some embodiments, the data of data store  110  may comprise one or more of conventional tabular data, row-based data, column-based data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. Data store  110  may support multi-tenancy to separately support multiple unrelated clients by providing multiple logical database systems which are programmatically isolated from one another. 
     Data store  110  may implement an “in-memory” database, in which a full database stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks (not shown). Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database). 
     System  100  may be located on-premise according to some embodiments. According to other embodiments, server  130 , DBMS  120  and data store  110  are located off-site (e.g., in the Cloud) and are accessed via client  140  over Web protocols. 
       FIG. 2  comprises a flow diagram of process  200  according to some embodiments. In some embodiments, various hardware elements of system  100  execute program code to perform process  200 . Process  200  and all other processes mentioned herein may be embodied in computer-executable program code read from one or more of non-transitory computer-readable media, such as a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, and a magnetic tape, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software. 
     Initially, at S 210 , a request to display a visualization is received. The request may be received from a user operating a user interface presented by a Web browser executing on a client system (e.g., a desktop computer, a tablet computer, a mobile phone). More particularly, the user interface may be presented as a result of execution of a Web application by an execution engine of a Web browser. For example, the request may comprise a request for a chart of sales data for several geographical regions over a certain time period. 
     In response to the received request, a cached version of the visualization is rendered and displayed at S 220 .  FIG. 3  illustrates system  300  to illustrate process  200  according to some embodiments. As shown, data visualization application  332  is executed by client system  330  and receives the request to display a visualization at S 210 . According to some embodiments, a cached version of the visualization is retrieved from cached visualizations  334  stored in a local storage (e.g., a local persistence) of client  330 . As will be described below, the cached version may have been stored in cached visualizations  334  as a result of a prior request for the data visualization.  FIG. 3  also illustrates interface  340  including the rendered cached visualization  345 . Interface  340  is presented on a display device of client system  330 . 
     Returning to process  200 , an “active” version of the data visualization is requested at S 230 . In some embodiments, the active version of the visualization is based on data stored in visualization source  310 . Accordingly, application  332  may request the data visualization from visualization source  310  at S 230 . Visualization source  310  may comprise a database platform such as server  130  and data store  110  of  FIG. 1 . 
     The active version may comprise current data associated with the visualization. The data may include sales figures and/or other measures that are known. The active version may comprise a description of a visualization incorporating such current data, for example, a JavaScript Object Notation file. 
     At S 240 , the active visualization is received and rendered in a hidden mode. For example, the active visualization may be rendered but not yet displayed as will be described below. 
     S 230  and S 240  may occur contemporaneously with S 220  according to some embodiments. For example, a main thread of application  332  may render and display the cached version while a worker thread requests the active visualization at S 230  and receives and renders the active visualization at S 240 . 
     Finally, at S 250 , the rendered active visualization is displayed in place of the displayed cached version.  FIG. 4  illustrates display of the rendered active visualization  350  in place of the displayed cached version. According to some embodiments, S 250  includes swapping the rendered visualizations in a manner which minimizes the visual disturbance to the user. For example, the cached version may be render in a first div which is displayed while the active visualization may be rendered in a second div co-located with the first div but which is not displayed. At S 250 , the divs are swapped to bring the active visualization to the front and remove the cached copy. 
     According to some embodiments, hovering a cursor over a displayed cached version (e.g., visualization  345 ) may result in display of a “loading” indicator icon, while hovering over a displayed active version (e.g., visualization  350 ) may result in display of a tooltip associated with the marks in the visualization. In some embodiments, the data of the active visualization (i.e., the data stored in visualization source  310  at the time of the request for the active visualization) may be identical to the data represented in the cached version, therefore the active visualization and the cached version are identical and the replacement at S 250  may be imperceptible. 
       FIG. 5  illustrates process  500  according to some embodiments. Process  500  may comprise an implementation of process  200 , but embodiments are not limited thereto. 
     Process  500  concerns the presentation of a “story” consisting of one or more data visualizations, or charts. Upon system start (e.g., initialization of data visualization application  135 ) at S 505 , all charts persisted in a central data store (e.g., visualization source  310 ) are synchronized to a client persistence (e.g., volatile memory, cache  334 ) located on a client system. The charts may be persisted in a serialized format (e.g., JSON) which represents a graphic view of a chart, including its constituent data. 
     A command to load a story is received at S 510 , and it is determined at S 515  whether all charts have been loaded, or rendered with current active data. For each chart in the story, it is determined at S 520  whether the chart is cached (i.e., stored locally on the client system) and, if so, the cached chart is rendered while contemporaneously fetching and rendering the corresponding active chart as described above. For example, the chart is deserialized at S 525  (e.g., to Scalable Vector Graphics Document Object Model (SVG DOM)) and rendered at S 530 . The SVG ViewBox attribute may be used to support fluid resizing of the displayed cached visualization relative to the size of the container. 
     After rendering the chart, active data for the chart is fetched from the data store at S 535 . The data may be fetched by a worker thread at S 535 , while the cached chart is being rendered by a main thread at S 530 . Once the data is received, the current, or active, chart is rendered at S 540  (e.g., by the main thread) and an indication (e.g., a “rendering complete” event) is provided at S 545 . The current chart is serialized at S 550  and stored in the client persistence, for example by overwriting the prior cached version of the chart, if any. 
     Flow returns to S 515  to determine whether all charts are loaded. If not, flow continues to S 520  with respect to a next chart in the story and flow proceeds as described above. Accordingly, flow cycles between S 515  through S 545  as described above until each chart in the story is rendered with active data. 
     Once it is determined at S 515  that all charts of the story have been loaded, an indication is provided at S 555  that rendering of the page is complete. The indication may comprise firing of a “page complete” event according to some embodiments. Next, at S 560 , the cache is synchronized from the client persistence to the data store. Synchronization may comprise overwriting older serialized versions of one or more of the charts stored in the data store with current up-to-date serialized versions which were created during process  500  as described above. Accordingly, at a next initialization of the same or another client system, the newer versions will be synchronized to the corresponding client persistence at S 505 . 
       FIG. 6  is a functional block diagram of system  600  according to some embodiments. System  600  may comprise an implementation of client system  140  or client system  330  described above, but embodiments are not limited thereto. In some embodiments, the Container of system  600  is the aforementioned story, and the Cache Consumer is a functional module of a data visualization application. Individual components are described in further detail below. 
     For performance reasons, storage of cached data does not operate directly against the local Client Persistence in some embodiments. Instead, an intermediate in-memory (e.g., volatile memory) or Transient Store is used to capture data to be cached. Writing back to the Client Persistence occurs when there is minimal activity on the main thread, or when performance is less critical. Similarly, synchronization may be performed between the Client Persistence and the Transient Store soon after container load to minimize contention on the main thread. These activities are abstracted out to a Storage Manager. The design of the Storage Manager is intended to work against any arbitrary store types as long as the stores implement a pre-defined Application Programming Interface. 
     Operations against persistent stores are typically asynchronous, and many Create, Read, Update and Delete (CRUD) operations being performed on container load may lead to interleaving between other container load-related operations. Operations against the Client Persistence may therefore be delegated to web worker threads to alleviate contention on the main thread. A generic Worker Manager service is introduced to spawn workers to handle arbitrary pieces of work as well as automatically manage worker state. The Worker Manager service is intended as a centralized service for all worker thread activities and helps to control application impact on user device resources, remove maintenance of multiple worker manager implementations, and de-couple worker logic from worker management logic. 
     The stores described herein may implement a cache eviction strategy to evict stale or undesirable visualization entries. The cache eviction strategy may be evaluated in the following order: Max Age, Max entries, Max size. Max Age corresponds to the last modified time of the entry, and may be evaluated first to ensure all entries that are deemed too old are removed as a highest priority. The maximum number of entries ordered by last access time, or Max entries, is evaluated next as a low-cost mean way of eliminating excess entries. Ordering by last access time prioritizes entries the user has read from most recently, assuming the entry has not already expired, which should be handled by the preceeding Max age eviction. The Max size of all entries in aggregate, ordered by last access time, is then evaluated. 
     Cache loading or eviction may be performed during application load or upon completing a story rendering. For example, at application load, a key may be fetched from the persistent Key Store, and the entry will be pruned in-memory as it is read from the Client Persistence. During a synchronization from Client Persistence t to Transient Store, entries will be pruned in-memory as they are read from the Client Persistence. After receiving an indication that rendering of a story page is complete, all entries in the Transient Store will be persisted (regardless of whether they have expired between application load and the page render complete indication), the Client Persistence is pruned, and the Key Store is pruned. 
     To facilitate efficient retrieval and reading of data for cache eviction, the Client Persistence may be indexed by created/accessed/modified time and size. In order for the stores created in the Client Persistence to be granular per story (e.g., to prevent read/write of all cached data of the application when only the data for one story is needed), one store per story may be created. Metadata for each store may be tracked in a master/lookup store, which can then be used for store management, including metadata such as last accessed/modified/created time and size in bytes. 
     As part of persistent caching/storage, it may beneficial to ensure space usage from different caches does not become too large. The Transient Store size may be determined by settings, and the Client Persistence may track usage via a master lookup store. 
     Encryption/decryption may be performed when reading and writing to and from the Client Persistence (not to/from the Transient Store). Accordingly, encryption/decryption can also be pushed into the worker thread. 
     Keys may be stored client-side using an indexed database in a separate store from the cached data. This storage uses the ability of the client to keep keys 100% opaque and reduces complexity in the design (e.g., server-client key synchronization, etc.). Keys may expire after some small amount of time (e.g., a few days), and be rotated. 
       FIG. 7  is a block diagram of apparatus  700  according to some embodiments. Apparatus  700  may comprise a general-purpose computing apparatus and may execute program code to perform any of the functions described herein. Apparatus  700  may comprise an implementation of client  140  or client  330  as described above. Apparatus  700  may include other unshown elements according to some embodiments. 
     Apparatus  700  includes processor(s)  710  operatively coupled to communication device  720 , data storage device  730 , one or more input devices  740 , one or more output devices  750  and memory  760 . Communication device  720  may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s)  740  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)  740  may be used, for example, to enter information into apparatus  700 . Output device(s)  750  may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer. 
     Data storage device  730  may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory  760  may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory. 
     Browser  732  may comprise program code executed by processor  710  to cause apparatus  700  to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus. 
     Cached visualizations  734  may also be stored in volatile memory such as memory  760  during operation as described above. Data storage device  730  may also store data and other program code for providing additional functionality and/or which are necessary for operation of apparatus  700 , such as device drivers, operating system files, etc. 
     The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein. 
     All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software. 
     Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.