RussianPatents.com
|
Transacted double buffering for graphical user interface rendering. RU patent 2519034. |
||||||||||||||||||||||
IPC classes for russian patent Transacted double buffering for graphical user interface rendering. RU patent 2519034. (RU 2519034):
|
FIELD: physics, computer engineering. SUBSTANCE: invention relates to computer engineering and particularly to applications which include a graphical user interface. A method of updating a graphical user interface (GUI) comprises steps of identifying a requested action which leads to repainting of part of the GUI, determining that the requested action includes delay in repainting said part of the GUI, transacting the requested action through initiation, in a parallel manner, of a double buffering control means which renders GUI updates and makes then invisible, and a splash screen stream which is displayed on a display, and sending the rendered GUI updates to the display at the completion of the transaction of the requested action. EFFECT: improved smoothness and responsiveness of displaying GUI updates by performing update off-screen or on a temporarily invisible screen layer until completion. 14 cl, 5 dwg
THE LEVEL OF TECHNOLOGY Typical graphics software applications include user interface (UI, UI) or graphical user interface (GUI, GUI). Examples of such applications are those which are performed within or with the operating system MICROSOFT WINDOWS applications a MICROSOFT CORPORATION. More specifically, examples may include software for automation of the institutional activity of the OFFICE® from MICROSOFT CORPORATION, the software for personal information management OUTLOOK® from MICROSOFT CORPORATION and software word processing MICROSOFT WORD from MICROSOFT CORPORATION. GUI graphical software application is usually composed of many elements. These elements may include various control elements, views, menus, toolbars, indicators or any number of other UI elements. While the total space display this application is often referred to as the "box" applications, various UI elements themselves can be considered "Windows" in the framework of visual display applications. At the level of software implementation of these different UI element or "window" can be named pointers on Windows or handles (descriptors) Windows. To display all the UI elements in the application, all related Windows within the application's display individually draw, render, or draw (display). This is usually done according sending a message paint (paint) or signal on each of the Windows or equally according call the paint method "window" object associated with each window in the display space applications. When the application is started or an operation that includes a redraw the component of Windows, the user can perceive partial or incomplete visualization application, because each component box shall be redrawn by the appearance randomly with different delays. An example of where this can occur is to download the file or resource on the network, occupying an indefinite amount of time. Other examples relate to the initial application startup or to switch views the application in the case when undertaking a large number of repeated calculation of display components. In appearance random delays and organise updates the UI components can distract or confuse the user. If there is a long delay, for example, some related to network boot, the user can face is partially drawn by the window for a long period. It can cause anxiety user that has failed. Such concerns may be established by the lack of clear, secure mechanism for a user to premature termination of the operation. For these and other considerations presented made this disclosure. THE ESSENCE OF THE INVENTION The paper describes the technology to improve user experience in visualization (rendering), or redraw the GUI interface. In particular, ways to establish associated with the user interface of the transaction, during which the visualization is the graphical user interface can be accessed by double-buffering. Long-term or delayed screen updates can be run outside of the screen or at the level of temporarily invisible screen until you are finished. After you complete the upgrade can be retrieved immediately on the screen. This can result to user experience (interface) improved smoothness and responsiveness. Update the graphics screen may vary called visualization, drawing, copying, drawing, or so on. According to one aspect, presented in the document, carried out in the mode of transaction draw or redraw the GUI can be initiated in response to a user action. The transaction can be installed, if a specific user action may require prolonged or indefinite amount of time. During the transaction visualization user interface can be double-buffered until the desired action is completed. The completion of the activity can be linked to status update UI inside the application, confirming that ended various necessary drawing operations of the screen. After you complete the requested action buffered dual image screen refresh may be submitted on screen display synchronously ("in unison")to appear almost instantly to the user. Such a conclusion buffering in the transaction mode can happen automatically in response to the completion of the requested action. According to another aspect presented in the document, double buffering screen updates can be run on many GUI elements, or Windows associated with the application. Single box, or UI element that can be double buffered image in a simple (one) buffer. In addition, multiple UI elements can be buffered separately. However, additional efficiency and work parameters can be ensured by double-buffering multiple UI elements associated with the application, in General double buffer for rendering. According to another aspect of this, is presented in the document, double-buffering can also be supported by drawing towards installed in full transparency OSD layer. Either one, or a combination of an off-screen buffer and transparent layer can be used to provide double buffering display the GUI. According to another aspect of this, is presented in the document that can provide feedback to the user about the progress or status of the requested action, which started the transaction. For example, opening a document over the network may require a long time. During this time, the user can be provided with information about the progress, while rendering his open file holds network operation. Progress can be displayed on the splash screen, which can be submitted, even if the actual display of the application currently dual image is buffered off screen or on a transparent layer. The splash screen can also include UI cancel, to provide the user with a secure way to cancel the operation. For example, if the user does not wish to continue to wait, or if the user realizes that he made a mistake in initiating the transaction. The splash screen, the progress indicator UI cancellation, and related operations can be executed in a separate thread, or other parallel operations separate from that carried out in the transaction mode, the action itself. This stream processing can support extremely responsive splash screen, even if the transaction mode action is in progress. You should appreciate that the above object of the invention may also be implemented in the form of a computer-controlled devices, computing process, computer system or in the form of products such as computer-readable media. These and various other signs will be obvious from reading the following detailed description and analysis of the associated drawings. This summary is shown that in a simplified form to submit a compilation of concepts that are further outlined below in the detailed description. This summary is not intended to identify the main features or essential features of the claimed subject matter, and no implication that this is a brief description is used to limit the amount of the declared object of the invention. In addition, the declared object of the invention is not limited to implementations that solve problems of any or all of the deficiencies observed in every part of this disclosure. BRIEF DESCRIPTION OF DRAWINGS Figure 1 - functional flowchart illustrating the mechanisms for double buffering graphical user interface along with displaying the splash screen according to the aspects of option exercise, presented in the document; Figure 2 - logical block diagram illustrating aspects of processes to improve rendering a graphical user interface according to the aspects of option exercise, presented in the document; Figure 3 - a logical block diagram illustrating aspects of the processes carried out in the transaction mode double-buffering for visualizing graphical user interface according to the aspects of option exercise, presented in the document; 4 is a logical block diagram illustrating aspects of the processes that sustain the splash screen in a graphical user interface according to the aspects of option exercise, presented in the document; and Figure 5 - an architectural diagram of a computer system that shows illustrative architecture hardware and computer software for computer systems capable of implementing aspects of option exercise, presented in the document. A DETAILED DESCRIPTION OF THE INVENTION Following the detailed description of technologies, designed to establish associated with the user interface of the transaction, during which the visualization of the graphical user interface can be accessed by double-buffering. Using the technologies and concepts presented in the document, a long-term or delayed screen refresh may be off screen or temporarily invisible layer of the screen until you are finished. After you complete the upgrade can be displayed on a visible screen as a single operation. This may result in practice of work of the user with improved responsiveness and smooth consistency. Although the object of the invention described in a paper presented in the General context of software modules, which are executed together with the performance of the operating system and application programs in a computer system, experts in the art recognise that can run other implementations in combination with other types of software modules. Usually, software modules include procedures, programs, components, data structures and other types of structures that perform specific tasks or implement specific abstract data types. In addition, experts in the art would appreciate that the object of the invention described in the document that can be implemented in practice with other computer systems, including portable devices, multiprocessor systems, microprocessor or programmable consumer electronics, mini-computers, mainframes and such. The following detailed description, refer to the accompanying drawings, which form part of it and show to illustrate specific ways of implementation or examples. Now appeal to the drawings, in which the same numeric reference positions are the same elements on several drawings will be described aspects of the computing system and methodology for establishing associated with the user interface of the transaction, during which the visualization of the graphical user interface can be accessed by double-buffering. Turning now to Figure 1, on the functional block diagram illustrates the system is 100 for double buffering graphical user interface along with displaying the splash screen 160 according aspects of option exercise, presented in the document. In particular, the graphical user interface associated with the application 110, can be presented on the display 190 computer. When a user initiated action can contain a long delay or indefinite amount of time, there may be delays between the redrawing parts of the user interface. This can provide a user perception prolonged partial display, spasmodic visualization or inconsistent display. Long delays can occur when the application loads, when you download a resource over the network when the edit view requires a re-calculation of elements of the display or when several other such conditions. Double buffering in the transaction mode can support smoother graphical user interface. Offscreen buffer 130 visualization can be equipped with a Manager (control program) 120 double buffering. Various component window representing the controls, menus, toolbars, Windows, and other user interface components associated with the application 110, can be hand-drawn or updated in the buffer 130 visualization, so that potentially speed, incomplete or spasmodic update the display were not visible to the user. As soon as the update UI completed, the buffer 130 visualization can "push" in the display 190 computer in a single operation. Such an implementation may allow to update the screen had a view of almost instantaneous. The update can be treated by the Manager of 120 double buffer. Manager 120 double buffer can apply the updates in the buffer 130 visualization on display 190 on request. Manager 130 double buffering may be part of the application software 110 or can be supported by the operating system, graphics, or Manager of the screen. Another mechanism for double buffering can use transparent layered box 140. When a component of an application cannot be modified to visualize update in relation to an offscreen buffer 130 visualization can be used approach with clear multilayer box 140. Application component can prevent modification of, if not available source code, when it is externally supplied by the library or component, such as an ACTIVEX control©, or when the interest of time, budget or transfer prevent code modifications. GUI component can be fitted with a transparent multi-layered box 140, on which it can draw its graphics update. Multi-layer window can use a graphical layer that is configured in full transparency so that potentially speed, spasmodic or delayed screen refresh invisible to the user. When the screen refresh was completed and updated the status of the UI, transparency can be changed to full opacity. Laminated box 140 so you can make visible to the user, in one operation, in order to make updates to appear almost instantly. Related to the user interface of the transaction can be used to manage many updates the UI that can be assembled together for double buffering. Many updates the UI in the framework of this transaction is usually associated with a specific user action, which may cause delays, such as primary application is opened, the file download over the network, change views UI within the application, or other such operations. During the transaction visualization user interface can be double-buffered until you have completed the requested action. If you can follow a long-term or unknown time of the transaction, the user can be presented with the screen-saver 160. Since the GUI can be updated in relation to the double buffering mechanism, such as an offscreen buffer 130 visualization or transparent layered box 140, the user can remain without updates of the screen if it is not intended to represent the splash screen 160. The splash screen is 160 can be supported by a flow of 150 splash screen. The flow of 150 splash screen can be part of the application software 110. The flow of 150 splash screen can be run as a separate thread, process, or other parallel mechanism, separate from the parts of the application software 110 relating to projects implemented in the transaction mode to user action. The selection of operations related to the splash screen, 160, in the flow of 150 splash screen can be a chance that the screen-saver 160 updated and processed responsive and interactive way, even if carried out in the transaction mode, the operation is in progress, and potentially delayed. The splash screen is 160, both supported by a flow of 150 splash screen, can provide the user with one or more indicators of the process. The progress of the process to provide the user with information about the actions performed and approximately how long can be related delays. An example of the progress indicator is the indicator of 170 implementation, which can show the percentage of progress for the action performed. The splash screen is 160, both supported by a flow of 150 splash screen, can provide the user UI cancellation. For example, a button 180 cancellation can be located on the splash screen, 160. Such a cancellation mechanism may provide you with a secure way to interrupt implemented in the transaction mode operation. For example, the user may not wish to continue, pending the completion of the requested action. This way the user can understand what initiating the transaction was made with an error. In situations such as these, the user can manipulate the UI cancel provided on the splash screen, 160. Now with circulation in figure 2 will be presented further details are presented in the document options for the implementation for double buffering graphical user interface while providing a while displaying the splash screen according to the aspects of option exercise, presented in the document. In particular, figure 2 shows a block diagram illustrating aspects of 200 to enhance the appearance of the graphical user interface. You should appreciate that logical operations described in document can be implemented (1), as a sequence implemented in a computer or software modules running in the computer system, and/or (2) in the form of interrelated diagrams machine logic or circuit modules within the computer system. Implementation is a matter of choice, depending on the working characteristics and other requirements to a computer system. Accordingly, logical operation, described in the document, referred to variously operations States, structural devices, actions or modules. These transactions are structured, actions and modules can be implemented in software, firmware, in the form of dedicated digital logic and any combination thereof. You should also appreciate that it can be done more or less than that shown on the drawings and described in the document. These operations can also be performed in series, parallel or in sequence, other than described in the document. If the transaction 220 determined that the action should not be in the transaction mode, the procedure 200 can continue operations 230, where the requested action can be performed without double buffered image GUI in the transaction mode. However, if in operation 220 determined that the action should be performed in the transaction mode, the procedure 200 can continue to start two operations in parallel. These two operations can be represented as the procedure 300 to perform the requested actions supported by the transaction, double-buffered image GUI, as well as the procedure 400, where can run the thread splash screen. Additional details relating to the procedure 300 and 400 below in relation to the figure 3 and Figure 4. Procedure 300 can supply signal progress on the procedure of 400 to update the status indicators related to the splash screen 160, such as the indicator of 170 implementation. In addition, the procedure 300 can put a completion signal to the procedure 400 for notification of completion of the transaction associated with the requested action. Procedure 200 may exit after return from a procedure 300 or after surgery 230 depending on the branch selected by the procedure 200. Now with the circulation figure 3 provides additional details are presented in the document options for the implementation for double buffering graphical user interface that provides the display of the splash screen according to the aspects of option exercise, presented in the document. In particular, figure 3 shows a block diagram illustrating aspects of the process 300 for double buffering in the transaction mode for visualizing graphical user interface. Procedure 300 begins in operation 310, where can be initiated transaction. Related UI transactions can be used to manage multiple updates the UI that can be assembled together in a double-buffering. Initiation of a transaction may mark the beginning of many UI updates, be double buffering. In operation 315 can be provided buffer 130 visualization. Usually, the buffer 130 visualization is provided in the form of an offscreen buffer to draw UI updates in it, without making them visible. Buffer 130 visualization may be provided by the Manager 120 double buffering. In operation 320 can be provided with transparent layered box 140. Transparent layered box 140 can also be provided by the Manager 120 double buffering. Transparent layered box 140 like an offscreen buffer 130 visualization because it can be made invisible to the user. However, transparent layered box 140 may actually be in the display space of transparency, set to "full"to be invisible. In operation 322 can be identified window as associated with the requested action. Different Windows can match GUI components used application software 110, while performs the requested action. These Windows GUI components may include controls, menus, view, toolbars, or any other Windows GUI components. In operations 325 may be drawing to a buffer 130 visualization while performing the requested action. In particular, drawing under Windows, identified in the operation 322, can use a buffer 130 visualization. For transactions with double buffering, update the UI-related operations (for example, the initial download of the application, change views, file access, network access, and so on)can be drawn into the buffer 130 visualization off screen, so that they were not visible to the user. Multiple UI components, or window can be double buffered image via shared buffer 130 visualization. In operation 330, drawing in a clear multilayer box 140 can be supported, as should. Update the UI double buffer against transparent layered window 140 can be appropriate when the UI code cannot be modified to render updates to an offscreen buffer 130 visualization. Application component, or window, as identified in the operation 322, can prevent modification of, if not available source code, when it is externally supplied library or component, such as an ACTIVEX control®, or when the interest of time, budget or transfer prevent code modifications. Instead of using an offscreen buffer 130 visualization, UI can perform their updates for transparent layered Windows 140, which is configured to be fully transparent. In operation 335 information about the progress can be supplied on stream 400 splash screen. Such information on the implementation can support on the splash screen, 160 display indicators of progress, such as the indicator of 170 implementation. These status indicators can provide the user with information on the transaction, while it is in progress. In operation 340, can be identified complete the requested action. For example, if the file is opened, can be identified completion open the file. Such identification may, in part, to provide support for automatically completing the transaction. In operation 345 may be detected peace (lack of input signals) to the state of the UI. Revealing that updates the UI were completed, may provide support binding completion supported by the transaction action status update UI within the application 110. Automatic termination of a transaction can be supported, in part, by defining a complete different necessary redraw events, such as the rendered text to be included buttons, disable buttons etc. In operation 350, completion of a transaction can be signaled on stream 400 splash screen. Notice flow 400 splash screen that the transaction was completed and now terminated, may provide support automatic termination of the thread 400 splash screen and may stop displaying the splash screen 160. In operation 355, updates that were made in the render buffer 130 in the middle of a transaction can be served on the display 190 computer. It may support Manager 120 double buffering. In cases where transparent layered box 140 was also used, filing bits buffer 130 visualization may include retrieve updates from the buffer 130 visualized in a clear multilayer box 140. In operation 360, transparent, multi-layered box 140 can be translated in which is fully opaque. Thus, transparency layered Windows can be switched off. In this same operation cumulative update the UI, associated with the transaction can be made visible to the user almost instantly. Thus, it can be maintained smoothing, less confusing user interface presentation. Procedure 300 may return to the procedure 200 after surgery 360. Now with circulation in Fig. 4, provides additional details on options for implementation, presented in the document for double buffering graphical user interface that provides the display of the splash screen according to the aspects of option exercise, presented in the document. In particular, figure 4 shows a block diagram illustrating aspects of the process 400 to support the splash screen in a graphical user interface. Procedure 400 starts in operation 410, where you can create an instance of the thread 150 splash screen. In operation 420, a flow of 150 splash screen can support the display of the splash screen 160, yet is carried out in the transaction mode, the user action. The flow of 150 splash screen can be part of the application software 110, but to be executed in a separate thread, process, or other parallelizing mechanism of the modules of the application software 110-related carried out in the mode of the transaction by a user action. This allocation in the flow of 150 splash screen operations related to the splash screen, 160, can give the possibility to the splash screen is 160 updated and processed responsive and interactive way, even if carried out in the transaction mode, the operation is in progress and potentially detained. In operation 430, the splash screen is 160, both supported by a flow of 150 splash screen, can provide the user with one or more indicators of the process. The progress of the process to provide the user with information about the actions performed and the approximate duration of which may be associated delays. An example of the progress indicator is the indicator of 170 implementation, which can show the percentage of progress associated with the performed action. In operation 440 splash screen 160, both supported by a flow of 150 splash screen, can provide the user UI cancellation. For example, on the splash screen, 160 can be located button 180 cancellation. Such a cancellation mechanism may provide you with a secure way to interrupt implemented in the transaction mode operation. For example, the user may not wish to continue, pending the completion of the requested action. This way the user can understand that the initiation of the transaction was completed with error. In situations such as these, the user can manipulate the UI cancel provided on the splash screen, 160. Custom action (interface) UI cancellation can be identified according to the operation 450. If cancellation is identified, it can be signaled on the application according operations 460. Alarm custom cancellation request on the application can provide support for the correct termination of the application requested action. After the operation 460 can be completed thread 150 splash screen and may be terminated by displaying the splash screen 160. Although no signal completion identified in operation 470, operation 480 can take from the procedure 300 signal progress, as discussed regarding the operation 335, illustrated in Figure 3. In operation 490, information about the progress, signaled to the procedure 400 in operation 480, can be used to update the progress of the process on the splash screen, 160, as provided for in operation 430. After the operation, 490, the procedure 400 may refund to the operation 450 and continue, as discussed above, until the transaction is canceled or completed. Turning now to Figure 5, illustrative architecture of computing systems can perform are described in the document software components for double buffering graphical user interface that provides the display of the splash screen. The computing system architecture, shown in Figure 5 illustrates the traditional desktop computer, a laptop computer or a server computer and can be used for performance of any aspect of any software provided in the paper. However, should assess, as described software components can also be performed in other approximate computing environments, such as mobile devices, television sets, set-top boxes, kiosks, mobile information systems, mobile phones, embedded systems, or other. The computing system architecture, illustrated in Figure 5, may include the CPU 10 (CPU, CPU), RAM 13, which includes random access memory 14 (RAM, RAM) and permanent memory 16 (ROM, ROM), and the system bus 11, which can link system memory 13 with CPU 10. The system basic input-output containing the main programs that help to transmit information between the components inside the computer 5, for example, during the run, can be stored in ROM 16. Computer 5 may optionally include a storage device 15 large capacity for storing operating system 18, software, data, and various software modules, for example, connected with application software 110. Application software 110 may execute the software components described in the document. Storage device 15 large capacity can be connected to the CPU through 10 mass storage controller high capacity (not illustrated)connected bus 11. Mass storage device capacity and related readable computer media can provide for your computer 5 nonvolatile memory. Although a computer-readable media, contained in document refers to mass storage such as a hard drive or on CDs, experts in the art must assess that read by the computer media can be any available media computer that can access the computer 5. As an example, and not limitation, read by the computer media can include volatile and non-volatile, removable and non-removable drives, implemented by any means or technology to store information, such as read by the computer instructions, data structures, software modules, or other data. For example, read by the computer media include but are not limited specified, RAM, ROM, erasable programmable ROM (EEPROM, EPROM), electrically erasable programmable ROM (EEPROM EEPROM), flash memory, or other technology of solid state memory, ROM in the CD-disk (CD-ROM), digital multifunction disc (DVD), HD DVD (high-density), disks BLU-RAY, or other optical memory, the memory on magnetic tapes, magnetic tape, magnetic disk, or other magnetic memory, or any other media that can be used to store the required information and which can be accessed through computer 5. According to the different variants of implementation of computer 5 may operate in a networked environment using logical connections to the remote computer through a network, such as the network 17. The 5 computer can connect to the network 17 through the block 19 of the network interface directly connected to the bus 11. You should appreciate that block 19 network interface can also be used to connect with other types of networks and remote computing systems. Computer 5 may also include a controller 12 I/o for the reception and processing of the input data from many other devices like a keyboard, mouse or stylus (not illustrated). Similarly controller 12 I/o can provide display 190 computer, printer, or other type of output device (also not illustrated). Display 190 alternative computer can be connected to the bus 11 through graphics card or CPU (also not illustrated). As briefly mentioned above, a number of software modules and the data files can be stored in memory 15 large capacity and RAM 14 5 computer, including the operating system 18, the right to control the use of network desktop computer, laptop computer, computer, server, or other computing environment. Storage device 15 large capacity, ROM 16 RAM and 14 can store one or more software modules. In particular, the storage device 15 large capacity, ROM 16 RAM and 14 can store application software 110 for execution by the CPU 10. Application software 110 may include software components for implementation of processes, discussed in detail regarding Fig. 1-4. Storage device 15 large capacity, ROM 16 RAM and 14 can also store other types of software modules. On the basis of the foregoing estimate that the paper presents the technology for double buffering in the transaction mode GUI, ensure the display of the splash screen. Although presented in the document object of the invention was described in a language-specific structural features, methodical action and computer-readable media computer, it should be understood that the invention, as defined in the attached claims, is not necessarily limited to a particular signs, actions or media, as described in the document. Preferred specific characteristics, actions and media disclosed in the form of form for the implementation of the claims. The above object of the invention is presented only as an illustration and should not be considered restrictive. You can run various modifications and changes in relation to the object of the invention described in the document, not following are illustrated and described the approximate variants of implementation and application, and without going beyond the true being and scope of the present invention, which is expressed in the following formula of the invention. 1. Implemented the computer how to update the graphical user interface (GUI)that contains the time that: by the computer processor find the requested action, which will result in redrawing at least one part of the GUI; by the computer processor determines that the requested action is brought delay in updating this at least one part of the GUI; by the computer processor perform a transaction requested action in response to a determination that the requested action can make the delay, by initiating parallel way, controls double buffering, which visualizes the update GUI associated with the transaction, and makes rendered update GUI invisible, and flow splash screen, which displays the splash screen, which includes the status led associated with the requested action, the monitor of the computer; and through the computer processor serves rendered update the GUI on the PC display on completion of the transaction requested action. 2. The method according to claim 1, wherein when rendering updates GUI and making rendered updates GUI render invisible rendered update the GUI in an offscreen buffer rendering. 3. The method according to claim 1, wherein when rendering updates GUI and making rendered updates GUI render invisible rendered update the GUI in a transparent, multi-layered window that is invisible. 4. The method according to claim 3, in which at submission by the computer processor rendered updates the GUI on the PC display make transparent layered window is visible. 5. The method according to claim 1, additionally contains a stage where, by the computer's processor displays the option of cancellation on the splash screen during a transaction requested action, and selecting cancel instructs the computer's processor to complete the transaction requested action. 6. The method according to claim 1, additionally contains a stage where, by the computer's processor produces a signal progress in the flow splash screen, which updates the status indicator on the basis of the progress of the rendering process updates the GUI management tool by double-buffering. 10. Computer data storage medium of claim 9, in which at submission by the computer processor rendered updates the GUI on the PC display transparent layered window is made visible. 11. Computer storage device according to claim 7, additionally contains Mashinostroenie teams that when they are performed by a computer instruct the computer to display the option of cancellation during a transaction requested action. 12. Computer data storage medium in paragraph 11, in which when you display options cancel the option to cancel appears on the splash screen, and selecting cancel instructs the computer to complete the transaction requested action. 13. Computer storage device according to claim 7, additionally contains Mashinostroenie teams that when they are performed by a computer tell the computer to give the signal progress in the flow splash screen, which updates the status indicator on the basis of the progress of the rendering process updates the GUI management tool by double-buffering. 14. Updater the graphical user interface (GUI)that contains the processor and computer readable media, which saved Mashinostroenie commands that while performing the processor instruct the device to find the requested action, which will result in redrawing at least one part of the GUI; determine that the requested action is brought one of the long delays and unknown delay in updating this at least one part of the GUI; to perform the transaction requested action on the basis of definition of what this action can make one of long delays and unknown delay, while the transaction provides parallel work management tools by double-buffering, which visualizes the update GUI associated with the transaction, and makes rendered update GUI invisible by rendering GUI updates in one or both of the offscreen buffer visualization and transparent layered Windows, which is invisible, and flow splash screen, which displays the splash screen, which includes the status led associated with the requested action on the computer screen; display the option to cancel on the screen-the splash screen during a transaction requested action, and selecting cancel instructs the device to complete the transaction requested action; to give the signal progress in the flow splash screen, which updates the status indicator on the basis of the progress of the rendering process updates the GUI management tool by double buffering; to issue a completion signal to the stream splash screen that provides notification of the completion of the transaction requested action; to complete the transaction requested action in response to the issuance of a completion signal to the stream splash screen; and serve rendered update the GUI on a computer display in response to the issuance of a completion signal to the stream splash screen.
|
© 2013-2014 Russian business network RussianPatents.com - Special Russian commercial information project for world wide. Foreign filing in English. |