Device configured to undo or redo drawing event and method therefor

Abstract

According to the present invention, proposed is a device configured to undo or redo a drawing event. The device may comprise: a memory configured to store a code configured to detect a drawing event input by means of a user interface and output a drawing object to the user interface according to the drawing event; and a processor configured to do the code for an operation for outputting the drawing object.

Description

A device configured to perform undo or redo of a drawing event and a method for the same

[0001] The present invention relates to an apparatus configured to perform the cancellation or redo of a drawing event and a method for doing the same, and more specifically, to an apparatus configured to perform the cancellation or redo of a drawing event and a method for doing the same, so as to perform loading for an object corresponding to the drawing event to be canceled or redoed without reloading all objects when a request for the cancellation or redo of a drawing event is made.

[0002]

[0003] In Fabric.js, Redo and Undo operations are features that allow you to revert or redo operations performed on the canvas (such as adding, deleting, moving, or transforming objects). While Fabric.js does not provide these features by default, implementing them requires saving and manipulating the operation history.

[0004] The basic principle is to save the canvas state and manage it so that it can be reverted or redoed, and the state is typically stored in JSON format. When an Undo is requested, the canvas is updated by retrieving the state prior to the current one; when a Redo is requested, the canvas is updated by advancing forward from the state reverted via Undo.

[0005] Since both Undo and Redo restore the canvas by retrieving the canvas state in JSON format, they consume a significant amount of time and computing resources. Consequently, the processing time for undo or redo is significantly delayed, causing inconvenience in the user experience.

[0006] Accordingly, this proposal aims to suggest a method for efficiently managing and updating the state of a canvas in response to undo or redo requests in drawing apps or services.

[0007]

[0008] The present invention relates to a method for efficiently managing and updating the state of a canvas in response to undo or redo requests in a drawing app or service.

[0009] The problems to be solved by the present invention are not limited to the problems to be solved above, and other problems not mentioned will be clearly understood by those skilled in the art to which the present invention belongs from the description below.

[0010]

[0011] According to the present invention, a device configured to perform undo or redo of a drawing event is proposed, wherein the device includes: a memory configured to store code configured to detect a drawing event input through a user interface and output a drawing object to the user interface according to the drawing event; and a processor configured to execute the code for an operation to output the drawing object, wherein the operation may include generating event history information for each individual drawing event for one object and storing the generated event history information in the memory, and updating a drawing canvas based on the stored event history information in response to the detection of a request to undo or redo of the drawing event.

[0012] Additionally or alternatively, the event history information may include an index of the event history information referenced by the event history information; and an index indicating the order in which the object was created.

[0013] Additionally or alternatively, the event history information referenced by the above event history information may include event history information for a previous version of the object indicated by the above event history information.

[0014] Additionally or alternatively, updating the drawing canvas may include rendering all objects according to an index indicating the order in which objects were created in the stored event history information.

[0015] Additionally or alternatively, the earlier the order in which the object is created, the lower the layer of the drawing canvas it can be rendered.

[0016] Additionally, or alternatively, the objects may be rendered on the drawing canvas in the order in which they were created.

[0017] Additionally or alternatively, the operation may include executing a command to update the drawing canvas according to the type of the drawing event of the event history information corresponding to the current index in response to the detection of a request to cancel the drawing event.

[0018] Additionally or alternatively, the operation may include executing a command to update the drawing canvas according to the type of the drawing event of the event history information corresponding to the next index of the current index in response to the detection of a request to re-execute the drawing event.

[0019] Additionally or alternatively, the above operation may include outputting an interface that queries whether to execute a request to cancel or redo a drawing event for an object selected or a specific object in the user interface.

[0020] Additionally or alternatively, the event history information may include a first index set for all objects and all drawing events; and a second index set for drawing events for each object.

[0021] Additionally or alternatively, the first index may indicate the overall order of drawing events, and the second index may indicate the order of drawing events per object.

[0022] Additionally or alternatively, the operation may include rendering the first object and the second object in the same state as before the modification drawing event occurred, as a request to undo the modification drawing event is detected after a modification drawing event occurs for a second object drawn earlier than the first object on the drawing canvas.

[0023] Additionally or alternatively, in response to the detection of a request to cancel the drawing event, the target object indicated by the event history information of the current index may be rendered according to the order in which the target object was created.

[0024] Additionally or alternatively, the type of the drawing event may include any one of a drawing event, a modification drawing event, or a deletion drawing event.

[0025] According to another embodiment of the present invention, a method for performing undo or redo of a drawing event is proposed, wherein the method is performed by a device configured to perform undo or redo of a drawing event, and the method may include the steps of: generating event history information for each individual drawing event for one object according to a drawing event input through a user interface and storing said generated event history information; and updating a drawing canvas based on said stored event history information in response to detection of a request to undo or redo of said drawing event.

[0026] Additionally or alternatively, the event history information may include an index of the event history information referenced by the event history information; and an index indicating the order in which the object was created.

[0027] Additionally or alternatively, the event history information referenced by the above event history information may include event history information for a previous version of the object indicated by the above event history information.

[0028] Additionally or alternatively, the step of updating the drawing canvas may include the step of rendering all objects according to an index indicating the order in which objects were created in the stored event history information.

[0029] Additionally or alternatively, the above method may include the step of rendering all the above objects on the drawing canvas in the order in which the objects were created.

[0030] According to another embodiment of the present invention, a computer-readable medium is proposed that stores code configured to be executed by a computer or processor for performing an undo or redo of a drawing event.

[0031] The above-mentioned problem-solving methods are merely some of the embodiments of the present invention, and various embodiments reflecting the technical features of the present invention can be derived and understood by those skilled in the art based on the detailed description of the present invention to be described below.

[0032]

[0033] The present invention has the following technical effects.

[0034] The present invention can significantly reduce processing time delays caused by undo or re-execution requests in drawing apps or services.

[0035] The present invention can significantly reduce memory usage resulting from undo or redo requests in drawing apps or services.

[0036] The effects according to the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the following detailed description of the invention.

[0037]

[0038] The accompanying drawings, which are included as part of the detailed description to aid in understanding the present invention, provide embodiments of the present invention and explain the technical concept of the present invention together with the detailed description.

[0039] Figure 1 illustrates the canvas state for drawing and undoing in a drawing app.

[0040] FIG. 2 illustrates an event history structure for storing a canvas state according to the present invention and restoring a canvas state following undo or redo.

[0041] Figure 3 shows the change in canvas state according to the modification request and undo request according to the present invention.

[0042] FIG. 4 illustrates an event history structure for storing a canvas state according to the present invention and restoring a canvas state following undo or redo.

[0043] Figure 5 shows the change in canvas state according to the modification request and undo request according to the present invention.

[0044] FIG. 6 shows an executed drawing event and a drawing event following an undo request according to the present invention.

[0045] FIG. 7 shows an executed drawing event and a drawing event according to a re-execution request according to the present invention.

[0046] FIG. 8 is a flowchart illustrating the process of updating the canvas state according to an undo request according to the present invention.

[0047] FIG. 9 is a flowchart illustrating the process of updating the canvas state according to a re-execution request according to the present invention.

[0048] FIG. 10 illustrates object-specific layer management according to the present invention.

[0049] Figure 11 illustrates the processing of an undo request according to the object-specific layer management method according to the present invention.

[0050] FIG. 12 illustrates the processing of a re-execution request according to the object-specific layer management method according to the present invention.

[0051] FIG. 13 shows the time required for a canvas state update according to the prior art and the present invention.

[0052] FIG. 14 illustrates a block diagram of a device configured to perform undo or redo of a drawing event according to the present invention.

[0053]

[0054] Hereinafter, embodiments disclosed in this specification will be described in detail with reference to the attached drawings. Identical or similar components regardless of drawing symbols will be assigned the same reference number, and redundant descriptions thereof will be omitted. The suffixes "module" and "part" used for components in the following description are assigned or used interchangeably solely for the ease of drafting the specification and do not inherently possess distinct meanings or roles. Furthermore, in describing embodiments disclosed in this specification, if it is determined that a detailed description of related prior art could obscure the essence of the embodiments disclosed in this specification, such detailed description will be omitted. Additionally, the attached drawings are intended only to facilitate understanding of the embodiments disclosed in this specification; the technical concept disclosed in this specification is not limited by the attached drawings, and it should be understood that they include all modifications, equivalents, and substitutions that fall within the spirit and technical scope of the present invention.

[0055] Terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but said components are not limited by said terms. These terms are used solely for the purpose of distinguishing one component from another.

[0056] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0057] A singular expression includes a plural expression unless the context clearly indicates otherwise.

[0058] In this application, terms such as “comprising” or “having” are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0059]

[0060] Figure 1 illustrates the canvas state for drawing and undoing in a drawing app.

[0061] As illustrated on the canvas, if an undo request occurs after the draw command for the four-leaf clover, the canvas is rendered with the four-leaf clover gone. When an undo request occurs, the state stored in the history information is loaded. For example, loadFromJSON() loads the canvas state prior to the draw command, but there is a problem in that a significant amount of time is consumed every time loadFromJSON() is executed.

[0062] Furthermore, since processing performance is more limited when handling such undo requests on devices other than PC environments, such as tablet PCs or TVs, more time is required as the number of objects on the canvas increases.

[0063]

[0064] FIG. 2 illustrates an event history structure for storing a canvas state according to the present invention and restoring a canvas state following undo or redo.

[0065] The event history structure (1) according to the present invention may include three pieces of information (11, 12, 13). Additionally, the event history may be created, stored, and managed to include each piece of information (11, 12, 13) one by one.

[0066] The reference index (11) is an index for indicating an event history that indicates a previous version of the object or the original object of the target object of the event. For example, an event history with an index (12) of “7” is shown as having a reference index (11) of “5”, which indicates that the event history refers to an event history with an index (12) of “5”, and means that the target objects of the two event histories are the same. As shown in FIG. 2, a distinguishing arrow is set to indicate a previous event history of the same object.

[0067] The object information (13) briefly indicates identical objects with the same uppercase alphabet and the version difference with '.

[0068] In this specification, an object is defined as a single stroke, or means a single image object.

[0069] Event history information according to the present invention can be independently defined and generated for individual drawing events (drawing, modification, deletion) and the target objects, and can be accumulated and stored in a storage medium such as memory.

[0070] The following shows an example of event history information for a total of 8 rows generated when a total of 8 drawing events occurred.

[0071] history: array (8)

[0072] 0: {prev: -1}, mode: 'draw', obj: klass}

[0073] 1: {prev: -1}, mode: 'draw', obj: klass}

[0074] 2: {prev: -1}, mode: 'draw', obj: klass}

[0075] 3: {prev: 0}, mode: 'select', obj: klass}

[0076] 4: {prev: 1}, mode: 'select', obj: klass}

[0077] 5: {prev: 3}, mode: 'select', obj: klass}

[0078] 6: {prev: 2}, mode: 'select', obj: klass}

[0079] 7: {prev: 5}, mode: 'select', obj: klass}

[0080] As shown in the following table, each element of the event history information can be organized for the 8 (row) event histories exemplified above.

[0081] Index Reference Index Event Type Object Information 0-1'draw'klass 1-1'draw'klass 2-1'draw'klass 30'select'klass 41'select'klass 53'select'klass 62'select'klass 75'select'klass

[0082] The index indicates the sequence number of the corresponding event history, numbered starting from 0 and increasing by 1. The reference index (prev) indicates the event history referenced by the corresponding event history. If there is no event history to reference, for example, when an object is newly added, the reference index (prev) is set to have a value of “-1”. The event type is set to indicate one of draw, select (including insertion and modification of image objects), or erase. The types of event types are merely examples, and more edit and modify events for more objects may be defined. Additionally, object information may be stored for each individual event history. The object information (obj) stores information about the corresponding object, which is omitted in this specification.

[0083] The event history (information) according to the present invention is not information that is deleted or changed despite the processing of a request to cancel or redo a drawing event.

[0084] The process of rendering an object on a canvas according to the present invention is briefly explained in relation to event information as follows.

[0085] A) Drawing

[0086] An object is determined based on user input, and event history information is generated based on the information about the determined object. In the case of drawing, the reference index (prev) is set to “-1”, and the index is set to a value increased by 1 from the most recent (largest) index.

[0087] With the event history shown in Table 1 created and saved, for example, when object d is newly drawn, a new event history with index=8 is created, and the object corresponding to index=8 is added to the canvas. Consequently, the canvas is based on the event history with indices = 4, 6, 7, and 8, and all objects (a, b, c, d) are rendered on the canvas.

[0088] In this case, the addition of object d due to the drawing event is recognized as the addition of a new object to the canvas, and accordingly, object d is positioned on the top layer of the canvas.

[0089]

[0090] B) Edit (select)

[0091] The selected object is modified based on user input, and event history information is generated based on the information about the modified object. In the case of modification (select), the reference index (prev) is set to an index value indicating the event history for the object in the previous state (or version) of the modified object, and the index is set to a value increased by 1 from the most recent (largest) index.

[0092] With the event history shown in Table 1 created and saved, for example, if object c is modified, a new event history with index=8 is created, the object corresponding to index=8 is added to the canvas, and the object corresponding to index=6 (i.e., object c in the previous state) is removed from the canvas. Consequently, the canvas is based on the event history with indices = 4, 7, and 8, and all objects (a, b, c) are rendered on the canvas.

[0093] In this case, the modification of object c due to the modification drawing event is recognized as the addition of a new object to the canvas (i.e., the addition of the modified object, which corresponds to index=8), and accordingly, object c is positioned on the top layer of the canvas.

[0094]

[0095] C) Delete (erase)

[0096] The selected object is deleted based on user input, and event history information is generated based on the information about the deleted object. In the case of deletion (erase), the reference index (prev) is set to an index value indicating the event history for the object in the previous state (or version) of the deleted object, and the index is set to a value increased by 1 from the most recent (largest) index.

[0097] With the event history shown in Table 1 created and saved, if, for example, object b is deleted, a new event history with index=8 is created, and the object corresponding to index=4 (i.e., object b in the previous state) is removed from the canvas. Consequently, the canvas is based on the event histories with indices = 6, 7, and 8, and all objects (a, c) are rendered on the canvas. (Object b is not rendered on the canvas because it is deleted.)

[0098]

[0099] In addition, the process of rendering an object on a canvas when an undo request occurs according to the present invention is briefly explained in relation to event information as follows.

[0100] When an undo request for a drawing event is input or detected, the current index corresponds to the canvas state prior to the input or detection of the undo request, and this can be determined as one of the indices of the previously created or stored event history information. Therefore, the event history (information) of the current index becomes the event history subject to undo. Additionally, the object information of the event history (information) of the current index becomes the object subject to undo. Below, each event type of the event history of the current index will be explained.

[0101] A) Drawing

[0102] If the event type of the event history at the current index is a drawing event, that is, if an undo request for a drawing event is entered or detected, the target object is removed from the canvas. Then, the current index can be decremented by 1.

[0103] As described above in the example of creating a new event history and rendering for a drawing event, when an undo request occurs or is detected after object d has been newly drawn and a new event history with index=8 has been created, the target object d is removed from the canvas.

[0104]

[0105] B) Revision

[0106] If the event type of the event history of the current index is a modification event, that is, if an undo request for a modification event is entered or detected, the target object is modified to the previous state or previous version of the object. Then, the current index can be decremented by 1.

[0107] To explain in more detail, the object corresponding to the object information of the event history indicated by the reference index (prev) of the event history of the current index is added to the canvas, and the target object is removed from the canvas.

[0108] However, in this case, since the previous state or previous version of the target object (hereinafter referred to as the “previous history object”) is added to the canvas as if it were the last event, regardless of the order of the event history prior to the receipt of the undo request, there is a problem in that the previous history object is rendered as if it were the last object drawn. This will be explained with reference to Fig. 3. This problem may occur in the case of a redo request as well as an undo request.

[0109] On the other hand, in the case of an “Edit Event,” an image object may have been added. In this case, the reference index of the event history at the current index will be “-1.” Therefore, even if an undo is requested for the “Edit Event,” only the removal of the target object from the canvas is performed.

[0110]

[0111] C) Delete

[0112] If the event type of the event history of the current index is a delete event, that is, if an undo request for a delete event is entered or detected, the target object is added back to the canvas. To be more specific, the object corresponding to the object information of the event history of the current index is added to the canvas. Then, the current index can be decreased by 1.

[0113] However, in this case, the previous state or previous version of the target object—that is, the previous history object—is added to the canvas as if it were the last event, regardless of the order of the event history before the undo request was received. Consequently, there is a problem in that the previous history object is rendered as if it were the last object drawn. This will be explained with reference to Fig. 3. This problem can occur in the case of a redo request as well as an undo request.

[0114]

[0115] Figure 3 shows the change in canvas state according to the modification request and undo request according to the present invention.

[0116] FIG. 3 is for three objects (a, b, c) drawn with a single stroke. The canvas state changes in the order of (a), (b), and (c) in FIG. 3. Additionally, the change in the canvas state in FIG. 3 indicates that it was performed based on the event history information according to the present invention proposed above.

[0117] FIG. 3(a) illustrates the state of the canvas drawn in the order of a, b, and c. FIG. 3(b) shows the result of a modification drawing event performed on object (b), and illustrates the canvas state where object (b) has been moved downwards as illustrated. FIG. 3(c) illustrates the state where object (b) has been restored to its previous state following an undo request.

[0118] However, regarding Fig. 3(c), when rendering an object on the canvas (as previously explained), the processing of an undo request for a drawing event is handled by i) removing the newly drawn object from the canvas, ii) adding the object in its pre-modification state to the canvas and removing the modified object from the canvas, or iii) adding the deleted object to the canvas. Therefore, in the case of ii) or iii), that is, in the case of an undo request for a modification drawing event or a deletion drawing event, contrary to expectations, the modified or deleted object may be placed differently from the object in the canvas state immediately before the target drawing event (of undo) occurs.

[0119] In the example illustrated in Fig. 3, if the user requests an undo in the canvas state of Fig. 3 (b), one can expect a canvas state like Fig. 3 (a); however, according to the canvas state restoration or object rendering method described above, the object (b) recognized as being added to the canvas last, as in Fig. 3 (c), is added at the very top. That is, a problem arises in which the target object of the drawing event of the undo request is rendered at the very top.

[0120] In other words, when a target object is added to the canvas, it is added last relative to the current canvas, unlike the stacking order at the time of its initial creation. Consequently, the canvas recognizes the target object as a new object, leading to a problem where the target object is added to the top layer.

[0121] To address this, the following event history structure is proposed.

[0122]

[0123] FIG. 4 illustrates an event history structure for storing a canvas state according to the present invention and restoring a canvas state following undo or redo.

[0124] In order to properly restore a target object in response to an undo or redo request, an index (Birthidx) (hereinafter referred to as the “object creation order index”) is proposed that indicates the order in which a target object or a previous history object was created.

[0125] Referring to FIG. 4, it is shown that the object creation order index (14) has been added in FIG. 3.

[0126] Based on Table 1, the state with added object creation order indices can be expressed as follows.

[0127] Index Reference Index Event Type Object Information Object Creation Order Index 0-1 'draw'klass11-1 'draw'klass22-1 'draw'klass330 'select'klass141 'select'klass253 'select'klass162 'select'klass375 'select'klass1

[0128] The object creation order index corresponds to or is identical to the number of objects associated with the created or saved event history, and the number does not change unless objects are added.

[0129] The event history (information) according to the present invention is not information that is deleted or changed despite the processing of a request to cancel or redo a drawing event.

[0130]

[0131] Figure 5 shows the change in canvas state according to the modification request and undo request according to the present invention.

[0132] FIG. 5 is for three objects (a, b, c) drawn with a single stroke. The canvas state changes in the order of (a), (b), and (c) in FIG. 5. Additionally, the change in the canvas state in FIG. 5 indicates that it was performed based on the event history information and object creation order index according to the present invention proposed above.

[0133] FIG. 5(a) illustrates the state of the canvas drawn in the order of a, b, and c. FIG. 5(b) shows the result of a modification drawing event performed on object (b), and illustrates the canvas state where object (b) has been moved downwards as illustrated. FIG. 5(c) illustrates the state where object (b) has been restored to its previous state following an undo request.

[0134] Unlike (c) in Fig. 3, (c) in Fig. 5 shows that object (b) is rendered in the same state as in (a) in Fig. 5. This is because all objects within the canvas are re-rendered using the object creation order index.

[0135] In relation to Fig. 5(c), when processing an undo request (as previously explained), the processing of the undo request for a drawing event is handled by i) removing the newly drawn object from the canvas, ii) adding the object in its pre-modification state to the canvas and removing the modified object from the canvas, or iii) adding the deleted object to the canvas. In the case of ii) or iii), that is, in the case of a modification event or a deletion event, even if the object in its pre-modification state or the deleted object is newly added to the canvas, all objects on the canvas are sorted according to the object creation order index, and then all objects are rendered, so the modified or deleted object can be arranged in the same way as the arrangement of the object in the canvas state immediately before the target drawing event (of undo) occurs.

[0136]

[0137] FIG. 6 illustrates the processing of objects within a canvas according to an executed drawing event and an undo request according to the present invention.

[0138] This shows the relationship between the previously executed drawing events (1100, 1200, 1300) and the processing method of the target object (2100, 2210, 2220, 2230) when the drawing events are undoed.

[0139] In the case of the modification event (1200), as previously explained, if the addition of an image object is undone, the added image object has no previous history object (i.e., reference index = -1), so only the removal of the target object from the canvas is required without adding a previous history object.

[0140]

[0141] FIG. 7 illustrates the processing of objects within a canvas according to an executed drawing event and a re-execution request according to the present invention. For reference, a re-execution request is a request that is possible only after an undo request has occurred and been processed. That is, the re-execution request is for the re-execution of an undo drawing event.

[0142] Represents the relationship between the processing method of the target object (2400, 2510, 2520, 2600) when a redo request is made after an undo request for a previously executed drawing event (1400, 1500, 1600).

[0143] In the case of the modification event (1500), as previously explained, when a request is made to undo and redo the addition of an image object, the added image object has no previous history object (i.e., reference index = -1), so only the addition of the target object to the canvas is required without removing the previous history object.

[0144]

[0145] FIG. 8 is a flowchart illustrating the process of updating the canvas state in response to an undo request according to the present invention. The process of FIG. 8 may be performed by a device (10) configured to perform the undo of a drawing event according to the present invention or by a processor of the device (10) configured to perform the undo of a drawing event. A detailed description of the device (10) configured to perform the undo of a drawing event will be provided later with reference to FIG. 14. Hereinafter, the device (10) configured to perform the undo of a drawing event will be simply referred to as the “device (10)”.

[0146] The device (10) may be configured to detect a request for undo for a drawing event (S810). Upon detection of a request for undo, the device (10) may be configured to determine a target drawing event to be undoed. This may be based on the event history information described above. In the case of a request for undo, the drawing event of the event history information corresponding to the current index may be determined as the target drawing event to be undoed. Specifically, the event type and object information of the event history information corresponding to the current index may be determined as the “target drawing event” and the “target object,” respectively. As described above in this specification, the current index is an index corresponding to the canvas state before the request for undo is detected, and this may be determined as one of the indices of the event history information that has been created or stored.

[0147] The device (10) can check whether the target drawing event to be undone is a drawing event of an object (S820). More specifically, it can check whether the event type of the target drawing event is “drawing”.

[0148] As the target drawing event to be undone is the drawing event of an object, the device (10) can be configured to remove the target object from the canvas (S830).

[0149] Alternatively, depending on whether the target drawing event to be undone is not a drawing event of an object, the device (10) can check whether the target drawing event to be undone is a select drawing event of an object (S840). More specifically, whether the event type of the target drawing event is “select” can be checked.

[0150] As the target drawing event to be undone is a modification drawing event of an object, the device (10) may be configured to add a previous state or previous version of the target object to the canvas, or to remove the target object from the canvas (S841). If there is no previous state or previous version of the object (e.g., a drawing event that newly adds an image object to the canvas), only the removal of the target object may be performed.

[0151] An object in a previous state or a previous version can be determined using the reference index of the target drawing event. The object represented by the object information of the drawing event corresponding to the reference index of the target drawing event corresponds to the object in the previous state or a previous version of the target object.

[0152] Alternatively, depending on whether the target drawing event to be undone is a modification drawing event of the object, i.e., the target drawing event is an erase drawing event, the device (10) may be configured to add the target object on the canvas (S850).

[0153] After that, the device (10) can be configured to sort all objects on the canvas using an object creation order index (S860).

[0154] The device (10) can be configured to render all aligned objects onto a canvas (S870).

[0155] According to the method illustrated in Fig. 8, when updating the canvas in response to an undo request, the problem described in relation to Fig. 3 can be resolved.

[0156] Meanwhile, the current index can be set to decrease by 1 at the same time the undo request is processed. This is because the canvas state has been updated, and the event history indicating this is a drawing event with an index one smaller than the target drawing event of the undo request.

[0157]

[0158] FIG. 9 is a flowchart illustrating the process of updating the canvas state according to a re-execution request according to the present invention. The process of FIG. 9 may be performed by a device (10) configured to perform a re-execution request after canceling a drawing event according to the present invention, or by a processor of the device (10) configured to perform a re-execution request after canceling a drawing event. A detailed description of the device (10) configured to perform a re-execution request after canceling a drawing event will be provided later with reference to FIG. 14. Hereinafter, the device (10) configured to perform a re-execution request after canceling a drawing event will be simply referred to as the “device (10)”.

[0159] The device (10) may be configured to detect a request for re-execution of a drawing event (S910). Upon detection of a request for re-execution, the device (10) may be configured to determine the target drawing event to be re-executed. This may be based on the event history information described above.

[0160] In the case of a redo request, the current index is an index corresponding to the canvas state prior to the detection of the redo request, and this can be determined as one of the indices of the previously created or stored event history information. Accordingly, in the case of a redo request, the drawing event of the event history information corresponding to the index that is 1 greater than the current index can be determined as the target drawing event to be redoed. This is because redoing targets a drawing event that has already been canceled. More specifically, the event type and object information of the event history information corresponding to the current index + 1 can be determined as the “target drawing event” and the “target object,” respectively.

[0161] The device (10) can check whether the target drawing event to be re-executed is a drawing event of an object (S920). More specifically, it can check whether the event type of the target drawing event is “drawing”.

[0162] As the target drawing event to be re-executed is a drawing event of an object, the device (10) can be configured to add a target object on the canvas (S930).

[0163] Alternatively, depending on whether the target drawing event to be re-executed is not a drawing event of an object, the device (10) can check whether the target drawing event to be re-executed is a modification (select) drawing event of an object (S940). More specifically, whether the event type of the target drawing event is “modification” can be checked.

[0164] As the target drawing event to be re-executed is a modification drawing event of an object, the device (10) may be configured to add a previous state or previous version of the target object to the canvas, or to remove the target object from the canvas (S941). If there is no previous state or previous version of the object (e.g., a drawing event that newly adds an image object to the canvas), only the addition of the target object may be performed.

[0165] An object in a previous state or a previous version can be determined using the reference index of the target drawing event. The object represented by the object information of the drawing event corresponding to the reference index of the target drawing event corresponds to the object in the previous state or a previous version of the target object.

[0166] Alternatively, depending on whether the target drawing event to be re-executed is a modification drawing event of the object, i.e., the target drawing event is an erase drawing event, the device (10) may be configured to remove the target object from the canvas (S950).

[0167] After that, the device (10) can be configured to sort all objects on the canvas using an object creation order index (S960).

[0168] The device (10) can be configured to render all aligned objects onto a canvas (S970).

[0169] According to the method illustrated in Fig. 9, when updating the canvas in response to an undo request, the problem described in relation to Fig. 3 can be resolved.

[0170] Meanwhile, the current index can be set to be incremented by 1 at the same time as the redo request is processed. This is because the canvas state has been updated, and the event history indicating this is the target drawing event of the redo request.

[0171]

[0172] FIG. 10 illustrates object-specific layer management according to the present invention.

[0173] Figure 10 shows an example with three objects on a canvas. The canvas may be composed of Layer 0, Layer 1, and Layer 2, and each layer may have one object located on it.

[0174] Once object-specific layers are defined in this way, in addition to the undo or redo requests based on the event history information explained earlier, it is also possible to make undo or redo requests for individual objects and process them.

[0175] Below, we will explain additional object event history information for object-specific layers.

[0176]

[0177] Figure 11 illustrates the processing of an undo request according to the object-specific layer management method according to the present invention.

[0178] Figure 11 (a) shows the event history for the objects “Cherry”, “Puppy”, and “Flower” in chronological order. Referring to Figure 11 (a), the drawing on the canvas in the order of Cherry, Puppy, and Flower is recorded in the event history.

[0179] The information represented by “Cherry X (Y)” indicates the order of operations (X) of the corresponding drawing event for the object “Cherry” in the overall drawing event for the canvas (i.e., the overall order of drawing events for the canvas) and the order of operations (Y) of the corresponding drawing event in the overall drawing event for the object “Cherry” (the order of drawing events per object). The same definition of the order of operations (X, Y) applies to the “Puppy” and “Flower” objects. The order of operations (Y) is the order of operations information valid only in the “Layer” described in FIG. 10, and the order of operations (X) is the order of operations information valid across the entire canvas.

[0180] Figure 11 (b) shows the result of processing the undo request for the “flower 11 (3)” drawing event in the state of Figure 11 (a). As “flower 11 (3)” is undoed, the target object corresponding to “flower 11 (3)” is removed from the canvas, and “flower 8 (2)” is added to the canvas, and the information of “flower 8 (2)” is modified to “flower 10 (2)”.

[0181] In addition, the information for the drawing event for the remaining object between the target drawing event of the undo request and the drawing event referenced by the target drawing event may also be modified. That is, the work order (X) information is modified so that “Cherry 9 (4)” becomes “Cherry 8 (4)” and “Puppy 10 (4)” becomes “Puppy 9 (4)”.

[0182] Figure 11 (c) shows the result of processing the undo request for the “Flower 10 (2)” drawing event in the state of Figure 11 (b). As “Flower 10 (2)” is undoed, the target object corresponding to “Flower 10 (2)” is removed from the canvas, “Flower 3 (1)” is added to the canvas, and the information of “Flower 3 (1)” is modified to “Flower 9 (1)”.

[0183] In addition, the information for the drawing events for the remaining objects between the target drawing event of the undo request and the drawing event referenced by the target drawing event may also be modified. That is, “Cherry 4 (2)”, “Cherry 6 (3)”, and “Cherry 8 (4)” are modified to “Cherry 3 (2)”, “Cherry 5 (3)”, and “Cherry 7 (4)”, respectively, and “Puppy 5 (2)”, “Puppy 7 (3)”, and “Puppy 9 (4)” are modified to “Puppy 4 (2)”, “Puppy 6 (3)”, and “Puppy 8 (4)”, respectively.

[0184]

[0185] FIG. 12 illustrates the processing of a re-execution request according to the object-specific layer management method according to the present invention.

[0186] Since Figures 12 (a) and 12 (b) are identical to Figures 11 (a) and 11 (b), the explanation will be omitted.

[0187] Figure 12 (c) shows the result of processing a redo request for the undo of the “Flower 10 (2)” drawing event in the state of Figure 12 (b). As the undo for “Flower 10 (2)” is redoed, the target object corresponding to “Flower 10 (2)” is deleted from the canvas, “Flower 11 (3)” is added to the canvas, and the information of “Flower 10 (2)” is changed to “Flower 8 (2)”.

[0188]

[0189] As illustrated in FIGS. 11 and 12, by including the overall operation sequence (X) and object operation sequence (Y) of the target object in each event history information and storing or managing them, it is possible to request undo or redo for a specific object and process the request.

[0190] For example, the device (10) may be configured to output a user interface on a human-machine interface, such as a display, and to output a user interface component that queries whether to execute an undo or redo request for a selected object or a specific object. When an undo or redo request for any object is input through the user interface component, the device (10) may perform the processing of the undo or redo of a drawing event for the object. The processing of the undo or redo of a drawing event is performed in the same manner as previously described, but additionally involves updating the overall work order (X) and the object work order (Y).

[0191] Additionally, while FIGS. 11 and 12 describe undoing or redoing for the last drawing event in relation to the overall work sequence (X), the present invention may also include a request for undoing or redoing for the last drawing event of each object and processing thereof, based on FIG. 11 (a).

[0192]

[0193] FIG. 13 shows the time required for a canvas state update according to the prior art and the present invention.

[0194] Figures 13 (a) and 13 (b) show the processing time when there are 30 objects on the canvas, and Figures 13 (c) and 13 (d) show the processing time when there are 100 objects on the canvas.

[0195] In addition, FIG. 13(a) and FIG. 13(c) show the processing time of the conventional method, that is, the method of storing and retrieving information about all objects of the canvas in JSON, and FIG. 13(b) and FIG. 13(d) show the processing time of an undo request based on event history information proposed in the present invention.

[0196] By utilizing the event history information proposed in this invention, it can be seen that the processing time of an undo request is independent of the number of objects. According to the conventional method, it can be seen that the more objects there are, the more time is required to render the canvas.

[0197]

[0198] FIG. 14 illustrates a block diagram of a device configured to perform undo or redo of a drawing event according to the present invention.

[0199] A device (10) configured to perform undo or redo of a drawing event may be configured to include memory (100) and a processor (101).

[0200] The memory (100) may be configured to store code configured to detect drawing events input through the user interface and output drawing objects to the user interface according to the drawing events.

[0201] The processor (101) may be configured to execute code stored in memory (100) for the operation of outputting a drawing object. More specifically, the processor (101) may be configured to generate event history information for each individual drawing event for a single object and to store said generated event history information in memory (100). Additionally, the processor (101) may be configured to update the drawing canvas based on the stored event history information in response to the detection of a request to cancel or re-execute a drawing event.

[0202] The event history information may include an index of the event history information referenced by the event history information; and an index indicating the order in which the object was created. Additionally, the event history information referenced by the event history information may include event history information for a previous version of the object indicated by the event history information.

[0203] Additionally, updating the drawing canvas may involve rendering all objects according to an index in the stored event history information indicating the order in which the objects were created. Accordingly, objects created earlier may be rendered on lower layers of the drawing canvas. Furthermore, objects may be rendered on the drawing canvas in the order in which they were created.

[0204] The processor (101) may be configured to perform a command to update the drawing canvas according to the type of the drawing event of the event history information corresponding to the current index in response to the detection of a request to cancel the drawing event.

[0205] The processor (101) may be configured to execute a command to update a drawing canvas according to the type of the drawing event of the event history information corresponding to the next index of the current index in response to the detection of a request to re-execute a drawing event.

[0206] In this specification, the type of drawing event may include any one of a drawing event, a modification drawing event, or a deletion drawing event.

[0207] The processor (101) may be configured to output an interface that queries whether to execute a request to cancel or redo a drawing event for a selected object or a specific object in the user interface.

[0208] Additionally, the event history information may include a first index set for all objects and all drawing events; and a second index set for drawing events for each object. The first index indicates the overall order of drawing events, and the second index may indicate the order of drawing events per object.

[0209] The processor (101) may be configured to render the first object and the second object in the same state as before the modification drawing event occurred, after a modification drawing event occurred for the second object drawn earlier than the first object on the drawing canvas and a request to undo the modification drawing event was detected.

[0210] Alternatively, in response to the detection of a request to undo a drawing event, the target object indicated by the event history information of the current index may be rendered according to the order in which the target object was created.

[0211] A device (10) configured to perform undo or redo of a drawing event may be configured to additionally include a human-machine interface (HMI) (102).

[0212] The human-machine interface (HMI) (102) includes means to provide visual or auditory notifications to a user or administrator, and may include, for example, a display. A user interface may be output to the HMI (102).

[0213] Even if not described with reference to FIG. 14, a device (10) configured to perform the cancellation or re-execution of a drawing event of the present invention may perform the operation according to the present invention as described above in FIG. 2 to FIG. 13.

[0214]

[0215] In addition, as another aspect of the present invention, the operation of the above-described proposal or invention may be provided as code that can be implemented, practiced, or executed by a "computer" (a comprehensive concept including a system on chip (SoC) or (micro)processor, etc.), or as a computer-readable storage medium or computer program product that stores or contains said code, and the scope of the present invention may be extended to said code or as a computer-readable storage medium or computer program product that stores or contains said code.

[0216]

[0217] The detailed description of the preferred embodiments of the present invention disclosed above is provided to enable those skilled in the art to implement and practice the present invention. Although the present invention has been described with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the present invention as described in the following claims. Accordingly, the present invention is not intended to be limited to the embodiments shown herein, but to be given the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A device configured to perform undo or redo of a drawing event, A memory configured to store code configured to detect a drawing event input through a user interface and to output a drawing object to the user interface according to the drawing event; and It includes a processor configured to execute the code for an operation to output the drawing object, and The above operation is: Event history information is generated for each individual drawing event for a single object, and the generated event history information is stored in the memory. A device comprising updating a drawing canvas based on the stored event history information in response to the detection of a request to cancel or redo the drawing event.

2. In paragraph 1, the above event history information is: The index of the event history information referenced by the above event history information; and A device comprising an index indicating the order in which the above objects were created.

3. In paragraph 2, the event history information referenced by the above event history information is, A device comprising event history information for a previous version of an object indicated by the above event history information.

4. In paragraph 1, updating the drawing canvas is: A device comprising rendering all objects according to an index indicating the order in which objects were created in the stored event history information.

5. A device according to paragraph 4, wherein the earlier the order in which the object is created, the lower the layer on which it is rendered on the drawing canvas.

6. A device according to paragraph 4, wherein the objects are rendered on the drawing canvas in the order in which they are created.

7. In paragraph 1, the above operation is: A device comprising, in response to the detection of a request to cancel the drawing event, performing a command to update the drawing canvas according to the type of the drawing event of the event history information corresponding to the current index.

8. In paragraph 1, the above operation is: A device comprising, in response to the detection of a request to re-execute the drawing event, performing a command to update the drawing canvas according to the type of the drawing event of the event history information corresponding to the next index of the current index.

9. In paragraph 1, the above operation is A device comprising outputting an interface that queries whether to execute a request to cancel or redo a drawing event for an object selected or a specific object in the above user interface.

10. In Paragraph 9, the above event history information is: A first index set for all objects and all drawing events; and A device comprising a second index set for a drawing event for each object.

11. In Paragraph 10, The above first index indicates the overall order of drawing events, and The above second index is a device that indicates the order of drawing events per object.

12. In paragraph 1, the above operation is: A device comprising rendering the first object and the second object in the same state as before the modification drawing event occurred, after a modification drawing event occurred for a second object drawn earlier than the first object on the drawing canvas, and upon detection of an undo request for the modification drawing event.

13. In Paragraph 2, In response to the detection of an undo request for the above drawing event, A device in which the target object indicated by the event history information of the current index is rendered according to the order in which the target object was created.

14. In paragraph 1, the type of the drawing event is: A device comprising any one of a drawing event, a modify drawing event, or a delete drawing event.

15. A method for performing undo or redo of a drawing event, wherein the method is performed by a device configured to perform undo or redo of a drawing event, and A step of generating event history information for each individual drawing event for a single object according to drawing events input through a user interface, and storing the generated event history information; and A method comprising the step of updating a drawing canvas based on the stored event history information in response to the detection of a request to cancel or re-execute the drawing event.

16. In Paragraph 15, the above event history information is: The index of the event history information referenced by the above event history information; and A method comprising an index indicating the order in which the above objects were created.

17. In Paragraph 16, the event history information referenced by the above event history information is, A method comprising event history information for a previous version of an object indicated by the above event history information.

18. In paragraph 15, the step of updating the drawing canvas is, A method comprising the step of rendering all objects according to an index indicating the order in which objects were created in the stored event history information.

19. In paragraph 18, the above method is, A method comprising the step of rendering objects on lower layers of the drawing canvas as the order in which the objects are created becomes earlier.

20. A computer-readable medium storing code configured to execute a method according to any one of paragraphs 15 through 19 by a computer or processor.

Images