CA2258005A1 - Lossless line compression - Google Patents
Lossless line compression Download PDFInfo
- Publication number
- CA2258005A1 CA2258005A1 CA002258005A CA2258005A CA2258005A1 CA 2258005 A1 CA2258005 A1 CA 2258005A1 CA 002258005 A CA002258005 A CA 002258005A CA 2258005 A CA2258005 A CA 2258005A CA 2258005 A1 CA2258005 A1 CA 2258005A1
- Authority
- CA
- Canada
- Prior art keywords
- sub
- path
- line
- coordinate
- graphical
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/001—Model-based coding, e.g. wire frame
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/20—Contour coding, e.g. using detection of edges
Abstract
In a distributed computer system, a method for lossless compression of a graphical line within an application server allows the compressed line data to be transmitted over a low bandwidth transport mechanism to a graphical user interface for display on a workstation. The application server determines, from graphical line data representative of the graphical line, coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path. The application server generates a compressed line data packet of variable length which includes the coordinate location data and attribute data for each sub-path of the graphical line.
Description
CA 022~800~ 1998-12-09 WO 9714807f PCTIUS97108998 LOSSLESS LI~JE COMPRESSION
Field of the Invention The invention relates generally to the field of data colllplession in a distributed computer system. In particular, the invention relates to a method for lossless colllple~ion of a graphical line, inr.lll~ing its attributes, within an application server before ~ n~ e the compressed line 5 data to the graphical user interface of a workstation over a low bandwidth communication transport mech~nicm Background of the Invention Distributed computer systems utilize the technique of di~Llil)uling an application execution. More specifically, an application server provides application execution services to 10 network users rather than running the application at the user's wolk~lalion. When an application runs, the application server intercepts the user's interface (e.g., the display screen, keyboard, and mouse) data and tr~n~mit.c/receives this data to/from a user program running at the user's wolk~lalion. For example, when an application involves graphical lines, the application server intercepts the graphical user interface and interacts with the user program to display lines on a 15 display at the user's wolk~lalion.
Graphical lines are frequently required in most processing operations and come in various forms, inr.lll~ling straight, arcs, ellipses, and bezier curves. In many distributed computer systems, it is desirable for the application server to communicate graphical line data to wolk~lalions over a low bandwidth communication transport merh~ni~m, such as serial lines, telephone lines, local 20 area nt;~wolk~ and wide area networks.
In one known implement~tion, graphical curved lines are tran~mitted by the application server as pixel coordinates, with each pixel definition being 7 bytes in length. However, every active pixel is tr~n~mitted as there is no interpolation method employed at the receiving workstation. If, for example, a small circle consists of 1000 active pixels, then 7000 bytes of data 25 is transmitted by the application server. Non-curved lines are tr~n.~mitted as pixel coordinates, CA 022~800~ 1998-12-09 WO 97/48077 PCTI~JS97/08998 with each pixel represented an endpoint to a straight line. The receiving workstation is responsible for interpolating between every two endpoints. Each endpoint is represented as 4 bytes, and each set of endpoints includes an additional header 27 bytes in length. For example, a simple straight line of two points requires 35 bytes (27+4~(2)). Using this known 5 impl~m~nt~tion, the tr~n~micsion of uncompressed data over a low bandwidth transport mech~ni.~m would be too slow for adequate usability.
It is thel efol e a principal object of this invention to provide a method for the lossless con~plession of lines in a distributed computer system that allows for the use low bandwidth comrnunication transport me~.h~ni~m, such as serial lines, telephone lines, local area networks and 10 wide area networks.
Summary of the Invention Accordingly, the present invention features a method for the lossless coml)lession of graphical line data for tr~n~mi~ion from an application server over a low bandwidth communication transport mer.l-~ ni~ to a graphical user interface of a workstation in a distributed 15 computer system. The graphical line data is representative of a graphical line to be displayed on a display screen of the wolk~Lalion.
In one embodiment, the lossless conlpl-ession method of the invention is realized within the application server. The application server determines, from graphical line data, coordinate locations for the endpoints of each sub-path of the graphical line. The application also determines 20 attributes of each sub-path from the graphical line data. The application server represents the coordinate locations as compressed coordinate location data of variable length and the attributes as co~nple~ed attribute data of variable length. The application server then generates a complessed line data packet of variable length which includes said colllpressed coordinate location data and said compressed attribute data for each sub-path.
The compressed line data packet generated by the application server fully defines the characteristics of the graphical line. The colllpl~ssed line data packet is transmitted over a low bandwidth communication transport mech~ni~m to the workstation. A decolllplession program in the ~o-k~lion determines the graphical line data (i.e., coordinate locations for the endpoints of each sub-path of the graphical line and aKributes of each sub-path) by decompressing the variable . .. . .. .. . .
CA 022~800~ 1998-12-09 length co~,lplessed line data packet. The graphical user interface uses the decompressed graphical lines data to display the graphical line on the display screen of the workstation.
The invention offers the following noteworthy features. First, the invention colllpresses graphical lines and their attributes with a high average compression ratio. Second, the invention S achieves lossless data compression (i.e., 100% reversible). Third, the invention does not require additional data for the decol.lpression processes Brief Description of the Drawin~s This invention is described with particularity in the appended claims. The above and further advantages of this invention may be better understood by referring to the following 10 description taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram of a distributed computer system.
FIG. 2 is a flow chart illustrating the basic graphical line compression method of the present invention.
FIG. 3 is a flow chart illustrating the basic line decompression method used in connection 15 with the line compression method of the invention.
FIG. 4 is a detailed flow chart illustrating that portion of the graphical line compression method of the invention pertaining to curved and complex non-curved lines.
FIG. 5 is a flow chart illustrating that portion of the graphical line compression method of the invention pertaining to colllpressillg endpoints.
FIG. 6 is a detailed flow chart illustrating that portion of the graphical line compression method of the invention pertaining to simple non-curved lines.
Detailed Description FIG. 1 is a schematic diagram of a distributed computer system incorporating theinvention. The system includes a host computer 10 coupled to a low bandwidth transport system 12 (e.g., a serial lines, telephone lines, a local area network or a wide area network). The application servers 14 provides application execution services to network user workstations 16.
When a user workstation wishes to run an application, the application server intercepts the user' s CA 022=,800=, 1998-12-09 W 097/48OM PCTrUS97/08998 int~rf~ce (e.g., the display screen, keyboard, and mouse) data and l~ /receives this data to/from a user program running at the user's workstation.
For applications involving graphical lines, the application server intercepts the graphical user interface and interacts with the user program to display lines on a display at the user' s S worl~.alion. Such lines may be in various forms inclll~ling: straight, arcs, ellipses, or bezier curves. In accordance with the present invention, the application server takes any graphical line and its attributes (e.g., color, position, orientation, and length) and compresses that information into a much smaller format. This collll)res~,on method is essential in a distributed computer system, where graphical line data is across low bandwidth communication transports.
The compression method of the present invention works for any lines and any lineattributes. When graphical lines are compressed in accordance with the invention, they can easily be decompressed by a decolllpression program in each user work~Lalion to their original form without any loss of information. In addition, the decompression program does not require any additional knowledge.
F~G. 2 is a flow chart illustrating the basic graphical line COlllpl ~ssion method of the present invention. When a user workstation initiates an application which requires a graphical line, the application server intercepts the graphical line data from the host computer (step 20).
The application server determines, from the graphical line data, coordinate locations for the endpoints of each sub-path of the entire path (i.e., the graphical line) (step 22). The application 20 also ~etcrmines the attributes of each sub-path from the graphical line data (step 24). The application server represents the coordinate locations and the attributes as colllpressed data of variable length (step 26). The application server then generates a compressed line data packet of variable length which includes said compressed coordinate location data and said compressed attribute data for each sub-path (step 28). The data packet generated by the application server 25 fully defines the characteristics of the graphical line. The length of the data packet varies depending upon the number of sub-paths and the number and complexity of the attributes for each sub-path.
Referring to FIG. 3, the data packet is tli.n~ ed over a low bandwidth co"llll~lnication transport mechanism and received by a decompression program within the workstation (step 30).
30 The program determines the graphical line data (i.e., coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path) by deco.l,pl ession of the CA 022~800~ 1998-12-09 variable length compressed line data packet (step 32). The graphical user interface uses the decompressed graphical lines data to display the graphical line on the display screen of the workstation (step 34).
FIG. 4 is a detailed flow chart illustrating that portion of the graphical line co"-pression S method of the invention pel ~aining to curved and complex non-curved lines. The term "path" (or "line") in~ des the attributes and endpoint data required for a complete line colllplession operation. Every path is comprised of one or more sub-paths, and a sub-path is a set of points which cnn~tit~ltes a logical subsection of a line.
This flow chart is implem~nted for all line co~ ression operations except for those which 10 meet the STROKEPATHSTRAIGHT rules (step 40). Only simple, non-curved lines meet these rules, which are set forth in detail in the Appendix section. Once it has been deterrnined that the line is not simple and non-curved, the first BYTE is set to 80 (Hex) to identify the protocol as STROKEPATH (step 42).
Next, the Flags BYTE is encoded (step 44). The Flags BYTE is applicable for all sub-15 paths in the line and includes attribute/pointer information (e.g., clipping, style, gap and color) for the line. If the color of the line is the sarne as the previous line compression operation, the fSamePen bit (b6) is set to ONE (step 46). If the color is di~l ~lll, the Pen BYTE is encoded (step 48). If the line has a mask-defined style, the Style bits (b2-b4) are set to Mask (step 50) and the Style Mask BYTE is encoded (step 52). If the line is solid, the Style bits are set to Solid (step 20 54) and steps 56 and 58 are skipped. If the line is not solid and the line is clipped in a non-trivial manner, the Clipping bits.(bO-bl) are set to Complex (step 56). If, however, the line is not solid and is not clipped in a non-trivial manner, the Style State BYTE is encoded (step 58).
If the line has an array-defined style, the Style bits are set to Array (step 60) and the Style Array Count BYTE and n Style Array WORDS are encoded (step 62). The Style Array Count is 25 the number of elements subrnitted in the Style Array. The Style Array consists of n WORDS, where n is the value of the Style Array Count. If the line is clipped to a single rectangle, the Clipping bits are set to Rectangle (step 66) and the Upper Half Boundary (3 BYTES) and Lower Half Boundary (3 BYTES) of the rectangle are encoded (steps 68, 70).
Next, the Sub-path Flags BYTE is encoded (step 72). This BYTE is applicable to the 30 proceeding sub-path only and prior to the set of sub-path endpoints. If the Style bits in the Flags CA 022~800~ 1998-12-09 wo 97/48077 PCTtUS97/08998 BYTE are set to solid (step 74), steps 76 and 78 are skipped. If the line is not solid and the Clipping bits in the Flags BYTE are set to Complex (step 76), the Complex Style State BYTE is encoded (step 76).
The Sub-path endpoints are then encoded (step 80) and explained in detail below. If the S Clipping bits in the Flags BYTE are set to Complex (step 82), then a Run Array of n DWORDS
are encoded (step 84) and the co.,.pression operation is complete (step 86).
FIG. 5 is a flow chart illustrating that portion of the graphical line compression method of the invention pertaining to the compression of endpoints. If there is no more endpoint data for the line, the fType bits (b5-b7) of the Sub-path Flags BYTE are set to EndData (step 90) and the 10 endpoint encoding process is complete (step g2). If the proceeding set of sub-path endpoints define a diagonal line, the fType bits are set to Diagonal (step 94) and a 3 BYTE (x,y) coordinate is encoded (step 96). If the proceeding set of sub-path endpoints define a vertical line, the fType bits are set to Vertical (step 98) and a one WORD coordinate is encoded (step 100). If the proceeding set of sub-path endpoints define a vertical line, the fType bits are set to Horizontal 15 (step 102) and a one WORD coordinate is encoded (step 104). If the proceeding set of sub-path endpoints define an ellipse, the fType bits are set to Ellipse (step 106) and a three (x,y) coordinates (3, 6 or 9 BYTES each) are encoded (steps 108-112). If the sub-path endpoints define a normal line, the fType bits are set to Normal and an (x,y) coordinate (3, 6 or 9 BYTES) is encoded (step 114). This process is repeated until all endpoints have been encoded.
FIG. 6 is a detailed flow chart illustrating that portion of the graphical line COlllpl ~ssion method of the invention pertaining to simple, non-curved lines. This flow chart is implemented only for line colllplession operations which meet the STROKEPATHSTRAIGHT rules (step 120). Only simple, non-curved lines meet these rules. Once it has been determined that the line is simple and non-curved, the first BYTE is set to 81 (Hex) to identify the protocol as 25 STROKEPATHSTRAIGHT (step 122).
There are always two endpoints in the line to be encoded. If the first point is the same as the last point of the previous line, fSamePoint is set to ONE (step 124) and only the second point is encoded (see steps 140-154). If not, fSamePoint is set to ZERO and the first point is encoded (step 124). If the first point is part of a diagonal line, the fType bits are set to Diagonal (step 128) 30 and a 3 BYTE (x,y) coordinate is encoded (step 130). If the first point is part of a vertical line, the fType bits are set to Vertical (step 132) and 3 BYTE (x,y) coordinate is encoded (step 134).
CA 022~800~ 1998-12-09 If the first point is part of a horizontal line, the fType bits are set to Horizontal (step 136) and 3 BYTE (x,y) coordinate is encoded (step 138).
Next, the second endpoint is encoded (step 140). If the second point is part of a diagonal line, the fType bits are set to Diagonal (step 142) and a 3 BYTE (x,y) coordinate is encoded (step 144). If the second point is part of a vertical line, the fType bits are set to Vertical (step 146) and 2 BYTE (y) coordinate is encoded (step 148). If the second point is part of a horizontal line, the fType bits are set to H~ olllal (step 150) and 2 BYTE (x) coordinate is encoded (step 152) and the process is complete (step 154).
Line Drawin~ Operation Protocol A detailed description ofthe STROKEPATH and STROKEPATHSTRAIGHT
protocol taken form the Citrix ICA 3.0 Thin Wire ~(~dendl-m - Revision 0.3 is provided in the Appendix attached hereto.
Equivalents While the invention has been particularly shown and described with reference to specific 15 prerelled embodiment~, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
CA 022~800~ 1998-12-09 APPENDIX: STROKEPATH and STROKEPATHSTRAIGHT Protocol I. STROKEPATH
For the following description of line drawing support, the term path is used to denote all of the characteristics and points of a complete STROKEPATH or STROKEPATHSTRAIGHTline drawing operation. Every path is comprised of one or more sub-paths. A sub-path is a set of points which conctitutes a logical sub-section of the complete line drawing operation.
The coordinates sent to the client are a col.lpless format of Microsoft's 28.4 fixed point format. The client sues these points to draw lines using Microsoft's run slice algorill~ , as shown in the Microsoft Windows NT DDK VGA driver sample.
This packet is used for all line drawing operations except for those which meet the STROKEPATHSTRAIGHT packet criteria. That is~ all line drawing operations which not satisfy all of the following criteria:
-Path consists of one and only one sub-path -Sub-path consists of only two points -Path uses the same pen (color & ROP2) as the last drawing operation -Line is solid -No clipping (not even simple rect clipping) -First point is either an integer or the same as the last point of the last drawing operation -Second point is an integer Protocol All multi-byte data entities used in STROKEPATH are submitted in order, from least significant byte to most significant byte.
The following con~tit~ltes the date stream for the STROKEPATH command packet:
BYTE 0x80 (STROKEPATH) always submitted BYTE Flags (applicable to all sub- always submitted paths) ~ Clipping (2bits) bl bO
Trivial: 0 0 - Clipping need not be considered; draw the whole CA 022~800~ 1998-12-09 figure.
Rectangle: O 1 - Clip to a single rectangle C~ 1PII-A~ I O - The line is clipped in a non-trivial manner.
I - reserved Remarks:
Rectangle - for this type of clipping, a boundary rectangle is submitted as part of the data stream (see Boundary l~c~gle below).
Complex - for this type of clipping, a run array is submitted as part of the data stream (see Run array below).
~ Style (3 bits) b4 b3 b2 Solid: O O O - Line is solid.
Alternate: O O I - Line is drawn with every other pixel displayed.
Dash: O I O - Line is drawn with dash style.
Dot: O I I - Line is drawn with dot style.
DashDot: I O O - Line is drawn with dash-dot style.
DashDotDot: 1 0 1 - Line is drawn with dash-dot-dot style.
Mask: I I O - Line is drawn with a bit mask-defined style.
Array: I 1 1 - Line is drawn with an array-defined style.
Remarks:
Dash - For this line style, the 8-bit style mask, 11001100, is to be used. See style mask, below, for a description of style masks.
Dot - For this line style, the 8-bit style mask, 10101010, is to be used.
DashDot - For this line style, the 8-bit style mask, 11100100, is to be used.
DashDotDot - For this line style, the 8-bit style mask, I 1101010, is to be used.
CA 022~800~ 1998-12-09 wo 97/48077 PCT/US97/08998 Mask - For this line style, an 8-bit style mask is submitted as part of the data stream (see style mask below).
Array - For this line style, a style array is submitted as part of the data stream (see style array below).
~ fStartGap (1 bit) b5 False: 0 - The style does not begin with a gap.
True: I - The style begins with a gap.
Style Mask - If fStartGap is True, the I 's in the style mask represent gaps, otherwise, the 0's represent gaps. See style mask, below, for a description of style masks.
Style Array - If fStartGap is True, the first entry in the style array specifies the length of the first gap, otherwise, the second entry in the style array specifies the length of the first gap.
See style array, below, for a description of style arrays.
~ fSamePen (lbit) b6 False: 0 - The color and/or ROP is di~elell~ from the last line draw operation.
True: 1 - The color and ROP is the same as in the last line draw operation.
E~rn~rk~: If fSamePen is False a pen is submitted as part of the data stream (see pen below).
~ reserved (1 bit) b7 0 - reserved.
0 - reserved.
0 - l he line is clipped in a non-trivial manner.
CA 022~800~ 1998-12-09 1 - reserved BYTE Pen (applicable to all sub-paths) submitted only if Flags.f~amePen is False ~ Raster operation [ROP2] (4 bits) b3 b2 bl bO
White: 0 0 0 0-1 Black: 0 0 0 1 - 0 NotMergePen: 0 0 1 0-DPon MaskNotPen: 0 0 1 1 - DPna NotCopyPen: 0 1 0 0 - PN
MaskPenNot: 0 1 0 1 - PDna Not: 0 1 1 0 -Dn XOrPen: 0 1 1 1 - DPx NotMaskPen: 1 0 0 0 - DPan MaskPen: 1 0 0 1 - DPa NotXOrPen: 1 0 1 0 - DPxn Nop: 1 0 1 I-D
MergePenNot: 1 1 0 0 - DPno CopyPen: 1 1 0 1 - P
MergePenNot: 1 1 1 0 - PDno MergePen: 1 1 1 1 - Dpo ~ Color (4 bits) b7 b6 bS b4 Color: x x x x Remarks: The pen is inclllded in the data stream if and only if the f~amePenvalue of the Flags byte is False. If fSarnePen is True, the same color and raster operation specified by the pen submitted in the last line drawing operation is to be used.
.. . .
CA 022~800~ 1998-12-09 BYTE Style Mask (applicable to all submitted only if Flags. Style is Mask sub-paths) Remarks: The style mask is included in the data stream if and only if the Style value of the Flags byte is Mask. If Style is a value other than Mask, this byte is not sent.
The style mask is 8 bits long (b7-bO), where each bit I epresel-~s one device unit length of line or gap.
Typically, a bit setting of O represents a gap, but if the fStartGap value of the Flags byte is True, then a 1 represents a gap.
BYTE Style State (applicable to all subrnitted only if Flags.Style is not sub-paths) Solid, and Flags.Clipping is not Complex Remarks: The style state is in~luded in the data stream if and only if the Style value of the Flags byte is not Solid and the Clipping value of the Flags byte is not Complex. If either - of these conditions are not met, this data is not sent.
The style state is a measure of where in the styling array to start the first sub-path.
s BYTE Style Array count (applicable submitted only if Flags.Style is Array to all sub-paths Remarks: The style array count is included in the data stream if and only if the Style value of the Flags byte is Array. If Style is a value other than Array, this byte is not sent.
. . . - t CA 022~800~ 1998-12-09 The style array count is the number of elements submitted in the proceeding style array (see style array, below, for a description of style arrays).
n WORDS Style Array (applicable to all sub-paths) submitted only if Flags. Style where n is the style array count. is Array pc~mArk~: The style array is in~ ded in the data stream if and only if the Style value of the Flags byte is Array. If Style is a value other than Array, this byte is not sent.
The style array consists of n WORDS, where n is the value of style array count. The first WORD in the array specifies the length of the first dash, the second specifies the length of the first gap, and so on.
4 6 BYTES Boundary rectangle (applicable to all sub-paths) submitted only if Flags.Clipping is ~ect~n~le The boundary rectangle is submitted as a three byte upper left hand point followed by a 1-3 byte X and Y de}ta:
Upper left hand point (3 BYTES - 24 bits) fType (3 bits) b2 b I bO Type of X and Y delta which follows 3dx5dy: O O O 3-bit X delta, 5-bit Y delta ( lBYTE).
5dx3dy: O O 1 5-bit X delta, 3-bit Y delta (lBYTE) 1 ldx5dy: O 1 O 1 l-bit X delta, 5-bit Y delta (2 BYTES) I IdxlOdy: O 1 1 1 I-bit X delta, 10-bit Y delta (3 BYTES) CA 022~800~ 1998-12-09 4dx4dy: 1 O O 4-bit X delta, 4-bit Y delta (1 BYTE) lOdx6dy: 1 O 1 10-bit X delta, 6-bit Y delta (2 BYTES) 6dxlOdy: I 1 O 6-bitXdelta, 10-bit delta(2 BYTES) 8dx8dy: 1 1 1 8-bitX delta, 8-bit Y delta(2 BYTES) Remarks: The value of fType indicates how many bytes follow which constitute the lower right hand X and Y coordinate deltas.
~ X coordinate (11 bits) bl3-b3 X -integer value of X coordinate . Y coordinate (10 bits) b23-bl4 y -integer value of Y coordinate ~ Lower right hand X and Y delta 3dx5dy:(1 BYTE) ~ X coordinate delta (3 bits) b2-bO
. Y coordinate delta (5 bits) b7-b3 4dx4dy:(1BYTE) . X coordinate delta (4 bits) b3-bO
. Y coordinate delta (4 bits) b7-b4 5dx3dy:(1 BYTE
. X coordinate delta (5 bits) b4-bO
CA 022~800~ 1998-12-09 . Y coordinate delta (3 bits) b7-b5 6dxlOdy:(2 BYTES) . X coordinate delta (6 bits) b5-bO
~ Y coordinate delta (10 bits) bl5-b6 8dx8dy:(2 BYTES) . X coordinate delta (8 bits) b7-bO
. Y coordinate delta (6 bits) b 1 5-b8 lOdx6dy:(2 BYTES) . X coordinate delta (10 bits) b9-bO
. Y coordinate delta (6 bits) blS-blO
I I dx5dy:(2 BYTES) . X coordinate delta (11 bits) blO-bO
. Y coordinate delta (5 bits) bl 5-bl 1 1 ldxlOdy:(3 BYTES) . X coordinate delta (1 1 bits) blO-bO
. Y coordinate delta (10 bits) b20-bl 1 . reserved (3 bits) b23-b21 Remarks:
The boundary rectangle is in~ ded in the data stream if and only if the Clipping value of the Flags byte is l~ct~le. If Clipping has a value other than Rectangle, this data is not sent.
The lower right hand coordinate is sent as O-based I . If (xl, yl) is the UHL coordinate and (x2,y2) is the LRH coordinate and (dx,dy) are the LRH deltas, then x2=xl+dx+1 and y2=yl+dy+l The boundary rectangle is used to clip the path. Any portions of the line which fall outside this boundary should not be drawn.
BYTE Sub-path Flags (applicable to the proceeding sub-path only) always submitted The sub-path flags byte is submitted prior to the set of sub-path points.
CA 022~800~ 1998-12-09 . fLast (1 bit) bO
False: O - There is another sub-path following the proceeding sub-path.
True: 1 - The proceeding sub-path is the last in the path.
Remarks:
True - If fLast is True, no more data will be sent after the proceeding set of sub-path points.
False If fLast is False, following the preceeding set of sub-path points, another sub-path flags byte and another set of sub-path points will be sent.
~ fSamePoint (1 bit) bl False: O-The first sub-path point is sent in the proceeding set of sub-path points.
True: l-The first point is not sent; the last point should be used as the first Rem~rk~
True: If fSarnePoint is True, the first point of the sub-path will not be inchlded in the proceeding set of sub-path points. ln~tca-~, the last point submitted in the last set of sub-path points will be used as the first point of the proceeding sub-path. The last point can be from the same or a di~el~n path.
False: If fSamePoint is False, the proceeding set of sub-path points, will include the first point in the sub-path.
. fBezier (1 bit) b2 False: O-The proceeding set of sub-path points do not define a Bezier curve.
True: l-The proceeding set of sub-path points define a Bezier curve.
Remarks:
fBezier will always be False if the client does not support the GCAPS_COMPLEX_CURVES capability.
True: If fBezier is True, the proceeding set of sub-path points will define either a Bezier curve or an ellipse variation. See fType, below, for information on T
CA 022~800~ 1998-12-09 dete,l~ f,llg the Bezier type. See Bezier Format, below, for a description of the Bezier format.
False: if fBezier is False, the proceeding set of sub-path points will consist of a set of points to be connected to form a line.
~ fClosed (1 bit) b3 False: 0-The proceeding set of sub-path points do not define a closed figure.True: I-The proceeding set of sub-path points define closed figure.
Remarks:
True: If fClosed is True, the first point in the sub-path which had the fNewStart bit set should be used also as the last point, in order to draw a closed figure.
False: If fClosed is False, the last point of the sub-path is included in the proceeding set of sub-path points.
~ fNewStart (1 bit) b4 False: 0-The proceeding set of sub-path points are a figure continuation.
True: 1-The proceeding set of sub-path points define a start of a new figure.
Remarks:
True: If fNewStart is True, the first point in the proceeding sub-path should be considered the start of a new figure and used as the last point if the fClosed bit is set.
False: If fNewStart is False, the proceeding set of sub-path points is a c-~ntin-l~tion of the previous subpath and does not constitute the start of a new closed figure.
~ fType (3 bits) b7 b6 b5 Normal: 0 0 0-The proceeding set of sub-path points define a normal line.
Horizontal: 0 0 1-The proceeding set of sub-path points define a horizontal line.
Vertical: 0 1 0-The proceeding set of sub-path points define a vertical line.
,, . . , .~, CA 022~800~ 1998-12-09 W O 97/48077 PCT~US97/~8998 Diagonal: 0 1 I-The proceeding set of sub-path points define a diagonal line.
Ellipse: 1 0 0-The proceeding set of sub-path points define an ellipse.
I 0 1-reserved.
1 1 0-reserved.
EndData: 1 1 l-There is no more data to be processed for this path.
Remarks:
Normal - If fType is Normal, all points will be sent in the proceeding set of sub-path points. See sub-path points, below, for a description of point formats.
Horizontal - If fType is Horizontal, the first point will be sent in the proceeding set of sub-path points. Only the X coordinate of the second point will be sent next, and will be in the one coordinate format. See the remarks, below, on the one coordinate format for more information. Note that the first point will not be sent if the fSamePoint value of the sub-points flags byte is True.
Vertical - If fType is Vertical, the first point will be sent in the proceeding set of sub-path points. Only the Y coordinate of the second point will be sent next, and will be in the one coordinate format. See the remarks, below, on the one coordinate format for more information. Note that the first point will not be sent if the fSamePoint value of the sub-points flags byte is True.
Diagonal - If fType is Diagonal, the proceeding set of sub-path points define a diagonal line consisting of only two points. See the sub-path points, below, for a description of point formats.
Ellipse - If fType is Ellipse, the proceeding set of sub-path points define an ellipse.
See the Ellipse format, below, for more hlru~ lion on this format.
EndData - if fType is EndData, another set of sub-path points will not be sent. The last sub-path set is considered the last sub-path in the path.
BYTE Complex Style State (applicable to this sub-path only) submitted only if Flags.Style is not Solid, and Flags.Clipping is Complex Remarks:
t CA 022~800~ 1998-12-09 WO g7/48077 PCI/US97/08998 The complex style state is included in the data stream if and only if the Style value of the Flags byte is not Solid and the Clipping value of the Flags byte is Complex. If either of - these conditions are not met, this data is not sent.
The complex style state is a measure of where in the styling array to start the sub-path.
This BYTE is sent for each subpath with complex clipping, after the sub-path flags and prior to the set of sub-path points.
2, 3, 4, or 9 BYTES (per point) Sub-path points always submitted (depending upon point forward - see below) The sub-path points data consists of one or more points in any of the standard formats, the Bezier format, the ellipse format, or the one coordinate format. The last point in the set is determined by the f~ast bit (see below).
~ Standard formats (24, 32, or 72 bits) The point, or (x,y) coordinate, is submitted as either 3, 4 or 4 BYTES, depending upon whether or not the X and/or Y coordinate contains a fractional components and/or is a negative value. The least ~ignific~nt three bits of each point are flags which are common for each the signed and unsigned, integer and rational formats.
~ fSigned (I bit) bO
False: O-Both x and y are unsigned values.
True: l-Both x and y are signed values.
Remarks:
True: If fSigned is True, this point is in either the 4 BYTE signed integer format, or the 9 BYTE signed rational format.
False: If fSigned is False, this point is in either the 3 BYTE unsigned integer 2~ format, or the 4 BYTE unsigned rational format.
~ ffnteger (1 bit) bl False: O-Both x and y are rational values.
True: l-Both x and y are integer values.
CA 022~800~ 1998-12-09 R~m~rk.~:
True: if ffnteger is True, this point is in either the 3 BYTE unsigned integer format, or the 4 BYTE signed integer format.
False: if ffnteger is False, this point is in either the 4 BYTE unsigned rationalformat, or the 9 BYTE signed rational format.
~ fLast (1 bit) b2 False: 0 - There is another point following this point.
True: 1 - This is the last point in the subpath.
I 0 R~m~rk~
True - If fLast is True, this point is the last in this sub-path.
False - If fLast is False, following this point, another point will be sent.
~ Unsigned integer format ~ X coordinate (11 bits) bl3-b3 x -unsigned integer value of X coordinate.
~ Y coordinate (10 bits) b23-bl4 y -unsigned integer value of Y coordinate.
20 Remarks:
The unsigned integer format is submitted if fSigned is False and ffnteger is True.
Points in this format total 3 BYTES.
~ Unsigned integer format ~ X coordinate (15 bits) bl7-b3 x -unsigned FIX value of X coordinate.
~ Y coordinate (14 bits) b3 l-bl 8 y -unsigned FIX value of Y coordinate.
. , I .. .
CA 022~800~ 1998-12-09 Remarks:
The unsigned rational format is submitted if fSigned is False and fInteger is False.
Points in this format total 4 BYTES.
~ Signed integer format . X coordinate (15 bits) bl7-b3 x -signed integer value of X coordinate.
Y coordinate (14 bits) b3 l-bl 8 y -signed integer value of Y coordinate.
Remarks:
The signed integer format is submitted if fSigned is True and ffnteger is True.
Points in this format total 4 BYTES.
~ Signed rational format . reserved (5 bits) b7-b3 res -reserved for future use.
X coordinate (32 bits) b39-b8 x -signed FIX value of X coordinate.
~ Y coordinate (32 bits) b7 1 -b40 y -signed FIX value of Y coordinate.
Remarks:
The signed rational format is submitted if fSigned is True and ffnteger is False.
Points in this format total 9 BYTES.
Remarks:
FIX - With the FIX format for rational format coordinates, the least significant 4 bits of the coordinate denote the fractional component, while the rçm~ining bits denote the integer .
CA 022~800~ 1998-12-09 component. The 4-bit fractional component represents the number of sixteenths of a unit.
The fractional component may be zero.
~ Bezier format The Bezier format of sub-path points is used if the fBezier value of the sub-path flags byte is True and the fType value of the sub-path flags byte is Normal. If the fType value is Ellipse, then the ellipse format is sent instead.
For the Bezier format, all points are sent in the standard format, where each point is in either the signed or unsigned, integer or rational formats. For a Bezier sub-path, the fSamePoint value of the sub-path flags byte still applies.
The data in this format consists of the end points and control points of the spline(s). The number of points in the sub-path is one more than three times the number of splines to be drawn (because each Bezier spline requires two control points and an endpoint, and the initial spline requires a starting point).
Rem~rk.c The cubic Bezier spline is drawn using the end points and control points specified by the set of sub-path points. The first spline is drawn from the first point to the fourth point by using the second and third points as control points. Each subsequent spline in the sequence needs exactly three more points: the ending point of the previous spline is used as the starting point, the next two points in the sequence are control points, and the third is the ending point.
20 ~ Ellipseformat The ellipse format is a special condensed variation of four bezier curves used to draw a circle or an ellipse. The format consists of three points:
FirstPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format. This point is not sent if fSamePoint of sub-path flags is True.
25 SecondPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format.
ThirdPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format.
Remarks:
The ellipse format will never be used if the GCAPS_COMPLEX_CURVES capability is not supported by the client.
CA 022~800~ 1998-12-09 The ellipse format can be easily expanded into a 13 point Bezier format using the following algorithm:
FIX ptBez[13]
FIX xLeft, xRight, yTop, yBottom FIX xBez2, yBezl FIX Ax, By, Cx, Dy xLeft = X coordinate of first point yTop = Y coordinate of first point xRight = X coordinate of second point yBottom = Y coordinate of second point xBez2 = X coordinate of third point yBezl = Y coordinate ofthird point Ax = (xRight - xLeft)/2 By = (yTop - yBottom)/2 Cx = xRight - xBez2 Dy = yTop - yBezl ptBez[O].x = xRight ptBez[O].y = yBottom + By ptBez[l].x = xRight ptBez[l].y = yBezl ptBez[2].x = xBez2 ptBez[2].y = yTop ptBez[3].x = xRight - Ax ptBez[3].y = yTop ptBez[4].x = xLeft + Cx ptBez[4].y = yTop ptBez[5].x = xLeft ptBez[5].y = yTop - Dy ptBez[6].x = xLeft ptBez[6].y = yTop - By . ~ . . ..... .. . . .
CA 022.7800.7 1998 - 12 - 09 ptBez[7].x = xLeft ptBez[7].y = yBottom + Dy ptBez[8].x = xLeft + Cx ptBez[8].y = yBottom ptBez[9].x = xLeft + Ax ptBez[9]y = yBottom ptBez[ l O] .x = xRight - Cx ptBez[10].y = yBottom ptBez[ 1 1 ] .x = xRight ptBez[1 1].y = yBottom + Dy ptBez[12].x = xRight ptBez[12].y = yBottom + By ~ one coordinate format (1 WORD) bl5-bO
f - Value of X or Y coordinate in FIX format.
.p.n~rk~:
The one coordinate format is used if the fType value of the sub-path flags byte is either Horizontal or Vertical. If frype is Horizontal, the value sent will be the X coordinate of the second point of the line. The Y coordinate will not be sent since it is the same as the Y coordinate of the first point.
If fType is Vertical, the value sent will be the Y coordinate of the second point of the line.
The X coordinate will not be sent since it is the same as the X coordinate of the first point.
Since horizontal and vertical lines are always only two points, the one coordinate value will always be the last data submitted in the sub-path.
Note that if the fSamePoint of the sub-path flags byte is True, the one coordinate value will be the only data in the sub-path.
n DWORDS Run Array submitted only if Flags.Clipping is Complex where n is the number of runs.
CA 022~800~ 1998-12-09 The run array data consists of one or more DWORD runs, each of which is comprised of some flags, a start position and a stop position. The last run in the array is determined by the fLast bit (see below).
fLast (1 bit) bO
False: O - There is another DWORD run following this run.
True: I - This is the last run in the subpath.
Remarks:
True - If fLast is True, this run is the last in this sub-path.
False - If fLast is False, following this run, another run will be sent.
reserved (I bit) bl O - reserved 1 - reserved Start position (15 bits) bl6-b2 start - start point for field of pizels to be drawn.
Stop position (15 bits) b3 1 -b 17 stop - stop point for field of pizels to be drawn.
Remarks:
The run array is inçhl~ed in the data stream if and only if the Clipping value of the Flags byte is Complex. If Clippin is a value other than Complex, this data is not sent.
The first pixel of the unclipped line is pixel zero.
If Flags. Clipping is Complex, the set of sub-path points will always be limited to two points, which should be connected using the start and stop positions defined by the run array.
... .
CA 022~800~ 1998-12-09 II. STROKEPATHSTR~GHT
This packet is used for straight line drawing operations not handled by the STROKEPATH
packet. That is, all line drawing operations which satisfy all of the following criteria:
- Path consists of one and only one sub-path S - Sub-path consists of only two points - Path uses the same pen (color & ROP2) as the last drawing operation - Line is solid - No clipping (not even simple rect clipping) - First point is either an unsigned integer or the same as the last point of the last drawing I O operation - Second point is an unsigned integer Protocol Note: All multi-byte data entities used in STROKEPATHSTRAIGHT are submitted in order, from least significant byte to most significant byte.
BYTE0X81(STOKEPATHSTR~GHT) always submitted 2-6 BYTES points always submitted There are always two points in the line to be drawn. If the least significant bit of the first byte sent, fSamePoint, is True, then that byte is part of the second (and last) point. If fSamePoint is False, then that byte is part of the first point, and the second point will immediately follow the first point.
The first point, if sent, is three bytes. The second point, which is always sent, is either two bytes or three bytes, depending upon whether just one coordinate of a horizontal or vertical line is sent.
All points sent, even the one coordinate variations, use a format where the three least significant bits or used as flags:
~ fSamePoint (1 bit) bO
False: O - This is the first point of the two-point line.
CA 022~800~ 1998-12-09 wO 97/48077 PCT/USg7/08998 Tme: I - The first point is not sent; the last point should be used as the first Rem~rk~
True - If fSamePoint is True, this is the second and last point of the line. The last point subrnitted in the last set of sub-path points will be used as the first point of this line.
False - If fSarnePoint is False, this is the first point of the two-point line. The last point is submitted next and will be two or three bytes, depending on the value of fType, below.
~ fType (2 bits) b2bl 0 0 - reserved.
Horizontal: 0 1 - This point is part of a horizontal line.
Vertical: I 0 - This point is part of a vertical line.
15 - Diagonal: I I - This point is part of a diagonal line.
Rem~rk~
Diagonal - If fType is Diagonal, the second point of the two-point line will bethree bytes and will consist of both the X and Y coordinates in unsigned integer format.
Horizontal - If fType is Horizontal, the second point of the two-point line will be two bytes and will consist of only the X coordinate in lln~igned integer format. The Y coordinate of the second point is the same as the Y coordinate of the first point.
Vertical - If fType is Vertical, the second point of the two-point line will be two bytes and will consist of only the Y coordinate in unsigned integer format. The X coordinate of the second point is the sarne as the X coordinate of the first point.
The first point and the diagonal line second point use the unsigned integer 3 BYTE format where the rem~ining bits are defined as:
~ X coordinate (11 bits) CA 022~800~ 1998-12-09 bl3-b3 x - unsigned integer value of X coordinate.
Y coordinate (10 bits) b23-bl4 s y - unsigned integer value of Y coordinate.
The second point of horizontal or vertical lines use the 2 BYTE format where the r~ g bits are defined as:
X or Y coordinate (13 bits) bl5-b3 u - Value of X or Y coordinate in unsigned integer format.
Remarks:
If frype is Horizontal, the value sent will be the X coordinate of the second point of the line. The Y coordinate will not be sent since it is the same as the Y coordinate of the first point.
If fType is Vertical, the value sent will be the Y coordinate of the second point of the line. The X coordinate will not be sent since it is the same as the X coordinate of the first point.
T
Field of the Invention The invention relates generally to the field of data colllplession in a distributed computer system. In particular, the invention relates to a method for lossless colllple~ion of a graphical line, inr.lll~ing its attributes, within an application server before ~ n~ e the compressed line 5 data to the graphical user interface of a workstation over a low bandwidth communication transport mech~nicm Background of the Invention Distributed computer systems utilize the technique of di~Llil)uling an application execution. More specifically, an application server provides application execution services to 10 network users rather than running the application at the user's wolk~lalion. When an application runs, the application server intercepts the user's interface (e.g., the display screen, keyboard, and mouse) data and tr~n~mit.c/receives this data to/from a user program running at the user's wolk~lalion. For example, when an application involves graphical lines, the application server intercepts the graphical user interface and interacts with the user program to display lines on a 15 display at the user's wolk~lalion.
Graphical lines are frequently required in most processing operations and come in various forms, inr.lll~ling straight, arcs, ellipses, and bezier curves. In many distributed computer systems, it is desirable for the application server to communicate graphical line data to wolk~lalions over a low bandwidth communication transport merh~ni~m, such as serial lines, telephone lines, local 20 area nt;~wolk~ and wide area networks.
In one known implement~tion, graphical curved lines are tran~mitted by the application server as pixel coordinates, with each pixel definition being 7 bytes in length. However, every active pixel is tr~n~mitted as there is no interpolation method employed at the receiving workstation. If, for example, a small circle consists of 1000 active pixels, then 7000 bytes of data 25 is transmitted by the application server. Non-curved lines are tr~n.~mitted as pixel coordinates, CA 022~800~ 1998-12-09 WO 97/48077 PCTI~JS97/08998 with each pixel represented an endpoint to a straight line. The receiving workstation is responsible for interpolating between every two endpoints. Each endpoint is represented as 4 bytes, and each set of endpoints includes an additional header 27 bytes in length. For example, a simple straight line of two points requires 35 bytes (27+4~(2)). Using this known 5 impl~m~nt~tion, the tr~n~micsion of uncompressed data over a low bandwidth transport mech~ni.~m would be too slow for adequate usability.
It is thel efol e a principal object of this invention to provide a method for the lossless con~plession of lines in a distributed computer system that allows for the use low bandwidth comrnunication transport me~.h~ni~m, such as serial lines, telephone lines, local area networks and 10 wide area networks.
Summary of the Invention Accordingly, the present invention features a method for the lossless coml)lession of graphical line data for tr~n~mi~ion from an application server over a low bandwidth communication transport mer.l-~ ni~ to a graphical user interface of a workstation in a distributed 15 computer system. The graphical line data is representative of a graphical line to be displayed on a display screen of the wolk~Lalion.
In one embodiment, the lossless conlpl-ession method of the invention is realized within the application server. The application server determines, from graphical line data, coordinate locations for the endpoints of each sub-path of the graphical line. The application also determines 20 attributes of each sub-path from the graphical line data. The application server represents the coordinate locations as compressed coordinate location data of variable length and the attributes as co~nple~ed attribute data of variable length. The application server then generates a complessed line data packet of variable length which includes said colllpressed coordinate location data and said compressed attribute data for each sub-path.
The compressed line data packet generated by the application server fully defines the characteristics of the graphical line. The colllpl~ssed line data packet is transmitted over a low bandwidth communication transport mech~ni~m to the workstation. A decolllplession program in the ~o-k~lion determines the graphical line data (i.e., coordinate locations for the endpoints of each sub-path of the graphical line and aKributes of each sub-path) by decompressing the variable . .. . .. .. . .
CA 022~800~ 1998-12-09 length co~,lplessed line data packet. The graphical user interface uses the decompressed graphical lines data to display the graphical line on the display screen of the workstation.
The invention offers the following noteworthy features. First, the invention colllpresses graphical lines and their attributes with a high average compression ratio. Second, the invention S achieves lossless data compression (i.e., 100% reversible). Third, the invention does not require additional data for the decol.lpression processes Brief Description of the Drawin~s This invention is described with particularity in the appended claims. The above and further advantages of this invention may be better understood by referring to the following 10 description taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram of a distributed computer system.
FIG. 2 is a flow chart illustrating the basic graphical line compression method of the present invention.
FIG. 3 is a flow chart illustrating the basic line decompression method used in connection 15 with the line compression method of the invention.
FIG. 4 is a detailed flow chart illustrating that portion of the graphical line compression method of the invention pertaining to curved and complex non-curved lines.
FIG. 5 is a flow chart illustrating that portion of the graphical line compression method of the invention pertaining to colllpressillg endpoints.
FIG. 6 is a detailed flow chart illustrating that portion of the graphical line compression method of the invention pertaining to simple non-curved lines.
Detailed Description FIG. 1 is a schematic diagram of a distributed computer system incorporating theinvention. The system includes a host computer 10 coupled to a low bandwidth transport system 12 (e.g., a serial lines, telephone lines, a local area network or a wide area network). The application servers 14 provides application execution services to network user workstations 16.
When a user workstation wishes to run an application, the application server intercepts the user' s CA 022=,800=, 1998-12-09 W 097/48OM PCTrUS97/08998 int~rf~ce (e.g., the display screen, keyboard, and mouse) data and l~ /receives this data to/from a user program running at the user's workstation.
For applications involving graphical lines, the application server intercepts the graphical user interface and interacts with the user program to display lines on a display at the user' s S worl~.alion. Such lines may be in various forms inclll~ling: straight, arcs, ellipses, or bezier curves. In accordance with the present invention, the application server takes any graphical line and its attributes (e.g., color, position, orientation, and length) and compresses that information into a much smaller format. This collll)res~,on method is essential in a distributed computer system, where graphical line data is across low bandwidth communication transports.
The compression method of the present invention works for any lines and any lineattributes. When graphical lines are compressed in accordance with the invention, they can easily be decompressed by a decolllpression program in each user work~Lalion to their original form without any loss of information. In addition, the decompression program does not require any additional knowledge.
F~G. 2 is a flow chart illustrating the basic graphical line COlllpl ~ssion method of the present invention. When a user workstation initiates an application which requires a graphical line, the application server intercepts the graphical line data from the host computer (step 20).
The application server determines, from the graphical line data, coordinate locations for the endpoints of each sub-path of the entire path (i.e., the graphical line) (step 22). The application 20 also ~etcrmines the attributes of each sub-path from the graphical line data (step 24). The application server represents the coordinate locations and the attributes as colllpressed data of variable length (step 26). The application server then generates a compressed line data packet of variable length which includes said compressed coordinate location data and said compressed attribute data for each sub-path (step 28). The data packet generated by the application server 25 fully defines the characteristics of the graphical line. The length of the data packet varies depending upon the number of sub-paths and the number and complexity of the attributes for each sub-path.
Referring to FIG. 3, the data packet is tli.n~ ed over a low bandwidth co"llll~lnication transport mechanism and received by a decompression program within the workstation (step 30).
30 The program determines the graphical line data (i.e., coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path) by deco.l,pl ession of the CA 022~800~ 1998-12-09 variable length compressed line data packet (step 32). The graphical user interface uses the decompressed graphical lines data to display the graphical line on the display screen of the workstation (step 34).
FIG. 4 is a detailed flow chart illustrating that portion of the graphical line co"-pression S method of the invention pel ~aining to curved and complex non-curved lines. The term "path" (or "line") in~ des the attributes and endpoint data required for a complete line colllplession operation. Every path is comprised of one or more sub-paths, and a sub-path is a set of points which cnn~tit~ltes a logical subsection of a line.
This flow chart is implem~nted for all line co~ ression operations except for those which 10 meet the STROKEPATHSTRAIGHT rules (step 40). Only simple, non-curved lines meet these rules, which are set forth in detail in the Appendix section. Once it has been deterrnined that the line is not simple and non-curved, the first BYTE is set to 80 (Hex) to identify the protocol as STROKEPATH (step 42).
Next, the Flags BYTE is encoded (step 44). The Flags BYTE is applicable for all sub-15 paths in the line and includes attribute/pointer information (e.g., clipping, style, gap and color) for the line. If the color of the line is the sarne as the previous line compression operation, the fSamePen bit (b6) is set to ONE (step 46). If the color is di~l ~lll, the Pen BYTE is encoded (step 48). If the line has a mask-defined style, the Style bits (b2-b4) are set to Mask (step 50) and the Style Mask BYTE is encoded (step 52). If the line is solid, the Style bits are set to Solid (step 20 54) and steps 56 and 58 are skipped. If the line is not solid and the line is clipped in a non-trivial manner, the Clipping bits.(bO-bl) are set to Complex (step 56). If, however, the line is not solid and is not clipped in a non-trivial manner, the Style State BYTE is encoded (step 58).
If the line has an array-defined style, the Style bits are set to Array (step 60) and the Style Array Count BYTE and n Style Array WORDS are encoded (step 62). The Style Array Count is 25 the number of elements subrnitted in the Style Array. The Style Array consists of n WORDS, where n is the value of the Style Array Count. If the line is clipped to a single rectangle, the Clipping bits are set to Rectangle (step 66) and the Upper Half Boundary (3 BYTES) and Lower Half Boundary (3 BYTES) of the rectangle are encoded (steps 68, 70).
Next, the Sub-path Flags BYTE is encoded (step 72). This BYTE is applicable to the 30 proceeding sub-path only and prior to the set of sub-path endpoints. If the Style bits in the Flags CA 022~800~ 1998-12-09 wo 97/48077 PCTtUS97/08998 BYTE are set to solid (step 74), steps 76 and 78 are skipped. If the line is not solid and the Clipping bits in the Flags BYTE are set to Complex (step 76), the Complex Style State BYTE is encoded (step 76).
The Sub-path endpoints are then encoded (step 80) and explained in detail below. If the S Clipping bits in the Flags BYTE are set to Complex (step 82), then a Run Array of n DWORDS
are encoded (step 84) and the co.,.pression operation is complete (step 86).
FIG. 5 is a flow chart illustrating that portion of the graphical line compression method of the invention pertaining to the compression of endpoints. If there is no more endpoint data for the line, the fType bits (b5-b7) of the Sub-path Flags BYTE are set to EndData (step 90) and the 10 endpoint encoding process is complete (step g2). If the proceeding set of sub-path endpoints define a diagonal line, the fType bits are set to Diagonal (step 94) and a 3 BYTE (x,y) coordinate is encoded (step 96). If the proceeding set of sub-path endpoints define a vertical line, the fType bits are set to Vertical (step 98) and a one WORD coordinate is encoded (step 100). If the proceeding set of sub-path endpoints define a vertical line, the fType bits are set to Horizontal 15 (step 102) and a one WORD coordinate is encoded (step 104). If the proceeding set of sub-path endpoints define an ellipse, the fType bits are set to Ellipse (step 106) and a three (x,y) coordinates (3, 6 or 9 BYTES each) are encoded (steps 108-112). If the sub-path endpoints define a normal line, the fType bits are set to Normal and an (x,y) coordinate (3, 6 or 9 BYTES) is encoded (step 114). This process is repeated until all endpoints have been encoded.
FIG. 6 is a detailed flow chart illustrating that portion of the graphical line COlllpl ~ssion method of the invention pertaining to simple, non-curved lines. This flow chart is implemented only for line colllplession operations which meet the STROKEPATHSTRAIGHT rules (step 120). Only simple, non-curved lines meet these rules. Once it has been determined that the line is simple and non-curved, the first BYTE is set to 81 (Hex) to identify the protocol as 25 STROKEPATHSTRAIGHT (step 122).
There are always two endpoints in the line to be encoded. If the first point is the same as the last point of the previous line, fSamePoint is set to ONE (step 124) and only the second point is encoded (see steps 140-154). If not, fSamePoint is set to ZERO and the first point is encoded (step 124). If the first point is part of a diagonal line, the fType bits are set to Diagonal (step 128) 30 and a 3 BYTE (x,y) coordinate is encoded (step 130). If the first point is part of a vertical line, the fType bits are set to Vertical (step 132) and 3 BYTE (x,y) coordinate is encoded (step 134).
CA 022~800~ 1998-12-09 If the first point is part of a horizontal line, the fType bits are set to Horizontal (step 136) and 3 BYTE (x,y) coordinate is encoded (step 138).
Next, the second endpoint is encoded (step 140). If the second point is part of a diagonal line, the fType bits are set to Diagonal (step 142) and a 3 BYTE (x,y) coordinate is encoded (step 144). If the second point is part of a vertical line, the fType bits are set to Vertical (step 146) and 2 BYTE (y) coordinate is encoded (step 148). If the second point is part of a horizontal line, the fType bits are set to H~ olllal (step 150) and 2 BYTE (x) coordinate is encoded (step 152) and the process is complete (step 154).
Line Drawin~ Operation Protocol A detailed description ofthe STROKEPATH and STROKEPATHSTRAIGHT
protocol taken form the Citrix ICA 3.0 Thin Wire ~(~dendl-m - Revision 0.3 is provided in the Appendix attached hereto.
Equivalents While the invention has been particularly shown and described with reference to specific 15 prerelled embodiment~, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
CA 022~800~ 1998-12-09 APPENDIX: STROKEPATH and STROKEPATHSTRAIGHT Protocol I. STROKEPATH
For the following description of line drawing support, the term path is used to denote all of the characteristics and points of a complete STROKEPATH or STROKEPATHSTRAIGHTline drawing operation. Every path is comprised of one or more sub-paths. A sub-path is a set of points which conctitutes a logical sub-section of the complete line drawing operation.
The coordinates sent to the client are a col.lpless format of Microsoft's 28.4 fixed point format. The client sues these points to draw lines using Microsoft's run slice algorill~ , as shown in the Microsoft Windows NT DDK VGA driver sample.
This packet is used for all line drawing operations except for those which meet the STROKEPATHSTRAIGHT packet criteria. That is~ all line drawing operations which not satisfy all of the following criteria:
-Path consists of one and only one sub-path -Sub-path consists of only two points -Path uses the same pen (color & ROP2) as the last drawing operation -Line is solid -No clipping (not even simple rect clipping) -First point is either an integer or the same as the last point of the last drawing operation -Second point is an integer Protocol All multi-byte data entities used in STROKEPATH are submitted in order, from least significant byte to most significant byte.
The following con~tit~ltes the date stream for the STROKEPATH command packet:
BYTE 0x80 (STROKEPATH) always submitted BYTE Flags (applicable to all sub- always submitted paths) ~ Clipping (2bits) bl bO
Trivial: 0 0 - Clipping need not be considered; draw the whole CA 022~800~ 1998-12-09 figure.
Rectangle: O 1 - Clip to a single rectangle C~ 1PII-A~ I O - The line is clipped in a non-trivial manner.
I - reserved Remarks:
Rectangle - for this type of clipping, a boundary rectangle is submitted as part of the data stream (see Boundary l~c~gle below).
Complex - for this type of clipping, a run array is submitted as part of the data stream (see Run array below).
~ Style (3 bits) b4 b3 b2 Solid: O O O - Line is solid.
Alternate: O O I - Line is drawn with every other pixel displayed.
Dash: O I O - Line is drawn with dash style.
Dot: O I I - Line is drawn with dot style.
DashDot: I O O - Line is drawn with dash-dot style.
DashDotDot: 1 0 1 - Line is drawn with dash-dot-dot style.
Mask: I I O - Line is drawn with a bit mask-defined style.
Array: I 1 1 - Line is drawn with an array-defined style.
Remarks:
Dash - For this line style, the 8-bit style mask, 11001100, is to be used. See style mask, below, for a description of style masks.
Dot - For this line style, the 8-bit style mask, 10101010, is to be used.
DashDot - For this line style, the 8-bit style mask, 11100100, is to be used.
DashDotDot - For this line style, the 8-bit style mask, I 1101010, is to be used.
CA 022~800~ 1998-12-09 wo 97/48077 PCT/US97/08998 Mask - For this line style, an 8-bit style mask is submitted as part of the data stream (see style mask below).
Array - For this line style, a style array is submitted as part of the data stream (see style array below).
~ fStartGap (1 bit) b5 False: 0 - The style does not begin with a gap.
True: I - The style begins with a gap.
Style Mask - If fStartGap is True, the I 's in the style mask represent gaps, otherwise, the 0's represent gaps. See style mask, below, for a description of style masks.
Style Array - If fStartGap is True, the first entry in the style array specifies the length of the first gap, otherwise, the second entry in the style array specifies the length of the first gap.
See style array, below, for a description of style arrays.
~ fSamePen (lbit) b6 False: 0 - The color and/or ROP is di~elell~ from the last line draw operation.
True: 1 - The color and ROP is the same as in the last line draw operation.
E~rn~rk~: If fSamePen is False a pen is submitted as part of the data stream (see pen below).
~ reserved (1 bit) b7 0 - reserved.
0 - reserved.
0 - l he line is clipped in a non-trivial manner.
CA 022~800~ 1998-12-09 1 - reserved BYTE Pen (applicable to all sub-paths) submitted only if Flags.f~amePen is False ~ Raster operation [ROP2] (4 bits) b3 b2 bl bO
White: 0 0 0 0-1 Black: 0 0 0 1 - 0 NotMergePen: 0 0 1 0-DPon MaskNotPen: 0 0 1 1 - DPna NotCopyPen: 0 1 0 0 - PN
MaskPenNot: 0 1 0 1 - PDna Not: 0 1 1 0 -Dn XOrPen: 0 1 1 1 - DPx NotMaskPen: 1 0 0 0 - DPan MaskPen: 1 0 0 1 - DPa NotXOrPen: 1 0 1 0 - DPxn Nop: 1 0 1 I-D
MergePenNot: 1 1 0 0 - DPno CopyPen: 1 1 0 1 - P
MergePenNot: 1 1 1 0 - PDno MergePen: 1 1 1 1 - Dpo ~ Color (4 bits) b7 b6 bS b4 Color: x x x x Remarks: The pen is inclllded in the data stream if and only if the f~amePenvalue of the Flags byte is False. If fSarnePen is True, the same color and raster operation specified by the pen submitted in the last line drawing operation is to be used.
.. . .
CA 022~800~ 1998-12-09 BYTE Style Mask (applicable to all submitted only if Flags. Style is Mask sub-paths) Remarks: The style mask is included in the data stream if and only if the Style value of the Flags byte is Mask. If Style is a value other than Mask, this byte is not sent.
The style mask is 8 bits long (b7-bO), where each bit I epresel-~s one device unit length of line or gap.
Typically, a bit setting of O represents a gap, but if the fStartGap value of the Flags byte is True, then a 1 represents a gap.
BYTE Style State (applicable to all subrnitted only if Flags.Style is not sub-paths) Solid, and Flags.Clipping is not Complex Remarks: The style state is in~luded in the data stream if and only if the Style value of the Flags byte is not Solid and the Clipping value of the Flags byte is not Complex. If either - of these conditions are not met, this data is not sent.
The style state is a measure of where in the styling array to start the first sub-path.
s BYTE Style Array count (applicable submitted only if Flags.Style is Array to all sub-paths Remarks: The style array count is included in the data stream if and only if the Style value of the Flags byte is Array. If Style is a value other than Array, this byte is not sent.
. . . - t CA 022~800~ 1998-12-09 The style array count is the number of elements submitted in the proceeding style array (see style array, below, for a description of style arrays).
n WORDS Style Array (applicable to all sub-paths) submitted only if Flags. Style where n is the style array count. is Array pc~mArk~: The style array is in~ ded in the data stream if and only if the Style value of the Flags byte is Array. If Style is a value other than Array, this byte is not sent.
The style array consists of n WORDS, where n is the value of style array count. The first WORD in the array specifies the length of the first dash, the second specifies the length of the first gap, and so on.
4 6 BYTES Boundary rectangle (applicable to all sub-paths) submitted only if Flags.Clipping is ~ect~n~le The boundary rectangle is submitted as a three byte upper left hand point followed by a 1-3 byte X and Y de}ta:
Upper left hand point (3 BYTES - 24 bits) fType (3 bits) b2 b I bO Type of X and Y delta which follows 3dx5dy: O O O 3-bit X delta, 5-bit Y delta ( lBYTE).
5dx3dy: O O 1 5-bit X delta, 3-bit Y delta (lBYTE) 1 ldx5dy: O 1 O 1 l-bit X delta, 5-bit Y delta (2 BYTES) I IdxlOdy: O 1 1 1 I-bit X delta, 10-bit Y delta (3 BYTES) CA 022~800~ 1998-12-09 4dx4dy: 1 O O 4-bit X delta, 4-bit Y delta (1 BYTE) lOdx6dy: 1 O 1 10-bit X delta, 6-bit Y delta (2 BYTES) 6dxlOdy: I 1 O 6-bitXdelta, 10-bit delta(2 BYTES) 8dx8dy: 1 1 1 8-bitX delta, 8-bit Y delta(2 BYTES) Remarks: The value of fType indicates how many bytes follow which constitute the lower right hand X and Y coordinate deltas.
~ X coordinate (11 bits) bl3-b3 X -integer value of X coordinate . Y coordinate (10 bits) b23-bl4 y -integer value of Y coordinate ~ Lower right hand X and Y delta 3dx5dy:(1 BYTE) ~ X coordinate delta (3 bits) b2-bO
. Y coordinate delta (5 bits) b7-b3 4dx4dy:(1BYTE) . X coordinate delta (4 bits) b3-bO
. Y coordinate delta (4 bits) b7-b4 5dx3dy:(1 BYTE
. X coordinate delta (5 bits) b4-bO
CA 022~800~ 1998-12-09 . Y coordinate delta (3 bits) b7-b5 6dxlOdy:(2 BYTES) . X coordinate delta (6 bits) b5-bO
~ Y coordinate delta (10 bits) bl5-b6 8dx8dy:(2 BYTES) . X coordinate delta (8 bits) b7-bO
. Y coordinate delta (6 bits) b 1 5-b8 lOdx6dy:(2 BYTES) . X coordinate delta (10 bits) b9-bO
. Y coordinate delta (6 bits) blS-blO
I I dx5dy:(2 BYTES) . X coordinate delta (11 bits) blO-bO
. Y coordinate delta (5 bits) bl 5-bl 1 1 ldxlOdy:(3 BYTES) . X coordinate delta (1 1 bits) blO-bO
. Y coordinate delta (10 bits) b20-bl 1 . reserved (3 bits) b23-b21 Remarks:
The boundary rectangle is in~ ded in the data stream if and only if the Clipping value of the Flags byte is l~ct~le. If Clipping has a value other than Rectangle, this data is not sent.
The lower right hand coordinate is sent as O-based I . If (xl, yl) is the UHL coordinate and (x2,y2) is the LRH coordinate and (dx,dy) are the LRH deltas, then x2=xl+dx+1 and y2=yl+dy+l The boundary rectangle is used to clip the path. Any portions of the line which fall outside this boundary should not be drawn.
BYTE Sub-path Flags (applicable to the proceeding sub-path only) always submitted The sub-path flags byte is submitted prior to the set of sub-path points.
CA 022~800~ 1998-12-09 . fLast (1 bit) bO
False: O - There is another sub-path following the proceeding sub-path.
True: 1 - The proceeding sub-path is the last in the path.
Remarks:
True - If fLast is True, no more data will be sent after the proceeding set of sub-path points.
False If fLast is False, following the preceeding set of sub-path points, another sub-path flags byte and another set of sub-path points will be sent.
~ fSamePoint (1 bit) bl False: O-The first sub-path point is sent in the proceeding set of sub-path points.
True: l-The first point is not sent; the last point should be used as the first Rem~rk~
True: If fSarnePoint is True, the first point of the sub-path will not be inchlded in the proceeding set of sub-path points. ln~tca-~, the last point submitted in the last set of sub-path points will be used as the first point of the proceeding sub-path. The last point can be from the same or a di~el~n path.
False: If fSamePoint is False, the proceeding set of sub-path points, will include the first point in the sub-path.
. fBezier (1 bit) b2 False: O-The proceeding set of sub-path points do not define a Bezier curve.
True: l-The proceeding set of sub-path points define a Bezier curve.
Remarks:
fBezier will always be False if the client does not support the GCAPS_COMPLEX_CURVES capability.
True: If fBezier is True, the proceeding set of sub-path points will define either a Bezier curve or an ellipse variation. See fType, below, for information on T
CA 022~800~ 1998-12-09 dete,l~ f,llg the Bezier type. See Bezier Format, below, for a description of the Bezier format.
False: if fBezier is False, the proceeding set of sub-path points will consist of a set of points to be connected to form a line.
~ fClosed (1 bit) b3 False: 0-The proceeding set of sub-path points do not define a closed figure.True: I-The proceeding set of sub-path points define closed figure.
Remarks:
True: If fClosed is True, the first point in the sub-path which had the fNewStart bit set should be used also as the last point, in order to draw a closed figure.
False: If fClosed is False, the last point of the sub-path is included in the proceeding set of sub-path points.
~ fNewStart (1 bit) b4 False: 0-The proceeding set of sub-path points are a figure continuation.
True: 1-The proceeding set of sub-path points define a start of a new figure.
Remarks:
True: If fNewStart is True, the first point in the proceeding sub-path should be considered the start of a new figure and used as the last point if the fClosed bit is set.
False: If fNewStart is False, the proceeding set of sub-path points is a c-~ntin-l~tion of the previous subpath and does not constitute the start of a new closed figure.
~ fType (3 bits) b7 b6 b5 Normal: 0 0 0-The proceeding set of sub-path points define a normal line.
Horizontal: 0 0 1-The proceeding set of sub-path points define a horizontal line.
Vertical: 0 1 0-The proceeding set of sub-path points define a vertical line.
,, . . , .~, CA 022~800~ 1998-12-09 W O 97/48077 PCT~US97/~8998 Diagonal: 0 1 I-The proceeding set of sub-path points define a diagonal line.
Ellipse: 1 0 0-The proceeding set of sub-path points define an ellipse.
I 0 1-reserved.
1 1 0-reserved.
EndData: 1 1 l-There is no more data to be processed for this path.
Remarks:
Normal - If fType is Normal, all points will be sent in the proceeding set of sub-path points. See sub-path points, below, for a description of point formats.
Horizontal - If fType is Horizontal, the first point will be sent in the proceeding set of sub-path points. Only the X coordinate of the second point will be sent next, and will be in the one coordinate format. See the remarks, below, on the one coordinate format for more information. Note that the first point will not be sent if the fSamePoint value of the sub-points flags byte is True.
Vertical - If fType is Vertical, the first point will be sent in the proceeding set of sub-path points. Only the Y coordinate of the second point will be sent next, and will be in the one coordinate format. See the remarks, below, on the one coordinate format for more information. Note that the first point will not be sent if the fSamePoint value of the sub-points flags byte is True.
Diagonal - If fType is Diagonal, the proceeding set of sub-path points define a diagonal line consisting of only two points. See the sub-path points, below, for a description of point formats.
Ellipse - If fType is Ellipse, the proceeding set of sub-path points define an ellipse.
See the Ellipse format, below, for more hlru~ lion on this format.
EndData - if fType is EndData, another set of sub-path points will not be sent. The last sub-path set is considered the last sub-path in the path.
BYTE Complex Style State (applicable to this sub-path only) submitted only if Flags.Style is not Solid, and Flags.Clipping is Complex Remarks:
t CA 022~800~ 1998-12-09 WO g7/48077 PCI/US97/08998 The complex style state is included in the data stream if and only if the Style value of the Flags byte is not Solid and the Clipping value of the Flags byte is Complex. If either of - these conditions are not met, this data is not sent.
The complex style state is a measure of where in the styling array to start the sub-path.
This BYTE is sent for each subpath with complex clipping, after the sub-path flags and prior to the set of sub-path points.
2, 3, 4, or 9 BYTES (per point) Sub-path points always submitted (depending upon point forward - see below) The sub-path points data consists of one or more points in any of the standard formats, the Bezier format, the ellipse format, or the one coordinate format. The last point in the set is determined by the f~ast bit (see below).
~ Standard formats (24, 32, or 72 bits) The point, or (x,y) coordinate, is submitted as either 3, 4 or 4 BYTES, depending upon whether or not the X and/or Y coordinate contains a fractional components and/or is a negative value. The least ~ignific~nt three bits of each point are flags which are common for each the signed and unsigned, integer and rational formats.
~ fSigned (I bit) bO
False: O-Both x and y are unsigned values.
True: l-Both x and y are signed values.
Remarks:
True: If fSigned is True, this point is in either the 4 BYTE signed integer format, or the 9 BYTE signed rational format.
False: If fSigned is False, this point is in either the 3 BYTE unsigned integer 2~ format, or the 4 BYTE unsigned rational format.
~ ffnteger (1 bit) bl False: O-Both x and y are rational values.
True: l-Both x and y are integer values.
CA 022~800~ 1998-12-09 R~m~rk.~:
True: if ffnteger is True, this point is in either the 3 BYTE unsigned integer format, or the 4 BYTE signed integer format.
False: if ffnteger is False, this point is in either the 4 BYTE unsigned rationalformat, or the 9 BYTE signed rational format.
~ fLast (1 bit) b2 False: 0 - There is another point following this point.
True: 1 - This is the last point in the subpath.
I 0 R~m~rk~
True - If fLast is True, this point is the last in this sub-path.
False - If fLast is False, following this point, another point will be sent.
~ Unsigned integer format ~ X coordinate (11 bits) bl3-b3 x -unsigned integer value of X coordinate.
~ Y coordinate (10 bits) b23-bl4 y -unsigned integer value of Y coordinate.
20 Remarks:
The unsigned integer format is submitted if fSigned is False and ffnteger is True.
Points in this format total 3 BYTES.
~ Unsigned integer format ~ X coordinate (15 bits) bl7-b3 x -unsigned FIX value of X coordinate.
~ Y coordinate (14 bits) b3 l-bl 8 y -unsigned FIX value of Y coordinate.
. , I .. .
CA 022~800~ 1998-12-09 Remarks:
The unsigned rational format is submitted if fSigned is False and fInteger is False.
Points in this format total 4 BYTES.
~ Signed integer format . X coordinate (15 bits) bl7-b3 x -signed integer value of X coordinate.
Y coordinate (14 bits) b3 l-bl 8 y -signed integer value of Y coordinate.
Remarks:
The signed integer format is submitted if fSigned is True and ffnteger is True.
Points in this format total 4 BYTES.
~ Signed rational format . reserved (5 bits) b7-b3 res -reserved for future use.
X coordinate (32 bits) b39-b8 x -signed FIX value of X coordinate.
~ Y coordinate (32 bits) b7 1 -b40 y -signed FIX value of Y coordinate.
Remarks:
The signed rational format is submitted if fSigned is True and ffnteger is False.
Points in this format total 9 BYTES.
Remarks:
FIX - With the FIX format for rational format coordinates, the least significant 4 bits of the coordinate denote the fractional component, while the rçm~ining bits denote the integer .
CA 022~800~ 1998-12-09 component. The 4-bit fractional component represents the number of sixteenths of a unit.
The fractional component may be zero.
~ Bezier format The Bezier format of sub-path points is used if the fBezier value of the sub-path flags byte is True and the fType value of the sub-path flags byte is Normal. If the fType value is Ellipse, then the ellipse format is sent instead.
For the Bezier format, all points are sent in the standard format, where each point is in either the signed or unsigned, integer or rational formats. For a Bezier sub-path, the fSamePoint value of the sub-path flags byte still applies.
The data in this format consists of the end points and control points of the spline(s). The number of points in the sub-path is one more than three times the number of splines to be drawn (because each Bezier spline requires two control points and an endpoint, and the initial spline requires a starting point).
Rem~rk.c The cubic Bezier spline is drawn using the end points and control points specified by the set of sub-path points. The first spline is drawn from the first point to the fourth point by using the second and third points as control points. Each subsequent spline in the sequence needs exactly three more points: the ending point of the previous spline is used as the starting point, the next two points in the sequence are control points, and the third is the ending point.
20 ~ Ellipseformat The ellipse format is a special condensed variation of four bezier curves used to draw a circle or an ellipse. The format consists of three points:
FirstPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format. This point is not sent if fSamePoint of sub-path flags is True.
25 SecondPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format.
ThirdPoint (3, 4, or 9 BYTES) in standard signed or unsigned, integer or rational format.
Remarks:
The ellipse format will never be used if the GCAPS_COMPLEX_CURVES capability is not supported by the client.
CA 022~800~ 1998-12-09 The ellipse format can be easily expanded into a 13 point Bezier format using the following algorithm:
FIX ptBez[13]
FIX xLeft, xRight, yTop, yBottom FIX xBez2, yBezl FIX Ax, By, Cx, Dy xLeft = X coordinate of first point yTop = Y coordinate of first point xRight = X coordinate of second point yBottom = Y coordinate of second point xBez2 = X coordinate of third point yBezl = Y coordinate ofthird point Ax = (xRight - xLeft)/2 By = (yTop - yBottom)/2 Cx = xRight - xBez2 Dy = yTop - yBezl ptBez[O].x = xRight ptBez[O].y = yBottom + By ptBez[l].x = xRight ptBez[l].y = yBezl ptBez[2].x = xBez2 ptBez[2].y = yTop ptBez[3].x = xRight - Ax ptBez[3].y = yTop ptBez[4].x = xLeft + Cx ptBez[4].y = yTop ptBez[5].x = xLeft ptBez[5].y = yTop - Dy ptBez[6].x = xLeft ptBez[6].y = yTop - By . ~ . . ..... .. . . .
CA 022.7800.7 1998 - 12 - 09 ptBez[7].x = xLeft ptBez[7].y = yBottom + Dy ptBez[8].x = xLeft + Cx ptBez[8].y = yBottom ptBez[9].x = xLeft + Ax ptBez[9]y = yBottom ptBez[ l O] .x = xRight - Cx ptBez[10].y = yBottom ptBez[ 1 1 ] .x = xRight ptBez[1 1].y = yBottom + Dy ptBez[12].x = xRight ptBez[12].y = yBottom + By ~ one coordinate format (1 WORD) bl5-bO
f - Value of X or Y coordinate in FIX format.
.p.n~rk~:
The one coordinate format is used if the fType value of the sub-path flags byte is either Horizontal or Vertical. If frype is Horizontal, the value sent will be the X coordinate of the second point of the line. The Y coordinate will not be sent since it is the same as the Y coordinate of the first point.
If fType is Vertical, the value sent will be the Y coordinate of the second point of the line.
The X coordinate will not be sent since it is the same as the X coordinate of the first point.
Since horizontal and vertical lines are always only two points, the one coordinate value will always be the last data submitted in the sub-path.
Note that if the fSamePoint of the sub-path flags byte is True, the one coordinate value will be the only data in the sub-path.
n DWORDS Run Array submitted only if Flags.Clipping is Complex where n is the number of runs.
CA 022~800~ 1998-12-09 The run array data consists of one or more DWORD runs, each of which is comprised of some flags, a start position and a stop position. The last run in the array is determined by the fLast bit (see below).
fLast (1 bit) bO
False: O - There is another DWORD run following this run.
True: I - This is the last run in the subpath.
Remarks:
True - If fLast is True, this run is the last in this sub-path.
False - If fLast is False, following this run, another run will be sent.
reserved (I bit) bl O - reserved 1 - reserved Start position (15 bits) bl6-b2 start - start point for field of pizels to be drawn.
Stop position (15 bits) b3 1 -b 17 stop - stop point for field of pizels to be drawn.
Remarks:
The run array is inçhl~ed in the data stream if and only if the Clipping value of the Flags byte is Complex. If Clippin is a value other than Complex, this data is not sent.
The first pixel of the unclipped line is pixel zero.
If Flags. Clipping is Complex, the set of sub-path points will always be limited to two points, which should be connected using the start and stop positions defined by the run array.
... .
CA 022~800~ 1998-12-09 II. STROKEPATHSTR~GHT
This packet is used for straight line drawing operations not handled by the STROKEPATH
packet. That is, all line drawing operations which satisfy all of the following criteria:
- Path consists of one and only one sub-path S - Sub-path consists of only two points - Path uses the same pen (color & ROP2) as the last drawing operation - Line is solid - No clipping (not even simple rect clipping) - First point is either an unsigned integer or the same as the last point of the last drawing I O operation - Second point is an unsigned integer Protocol Note: All multi-byte data entities used in STROKEPATHSTRAIGHT are submitted in order, from least significant byte to most significant byte.
BYTE0X81(STOKEPATHSTR~GHT) always submitted 2-6 BYTES points always submitted There are always two points in the line to be drawn. If the least significant bit of the first byte sent, fSamePoint, is True, then that byte is part of the second (and last) point. If fSamePoint is False, then that byte is part of the first point, and the second point will immediately follow the first point.
The first point, if sent, is three bytes. The second point, which is always sent, is either two bytes or three bytes, depending upon whether just one coordinate of a horizontal or vertical line is sent.
All points sent, even the one coordinate variations, use a format where the three least significant bits or used as flags:
~ fSamePoint (1 bit) bO
False: O - This is the first point of the two-point line.
CA 022~800~ 1998-12-09 wO 97/48077 PCT/USg7/08998 Tme: I - The first point is not sent; the last point should be used as the first Rem~rk~
True - If fSamePoint is True, this is the second and last point of the line. The last point subrnitted in the last set of sub-path points will be used as the first point of this line.
False - If fSarnePoint is False, this is the first point of the two-point line. The last point is submitted next and will be two or three bytes, depending on the value of fType, below.
~ fType (2 bits) b2bl 0 0 - reserved.
Horizontal: 0 1 - This point is part of a horizontal line.
Vertical: I 0 - This point is part of a vertical line.
15 - Diagonal: I I - This point is part of a diagonal line.
Rem~rk~
Diagonal - If fType is Diagonal, the second point of the two-point line will bethree bytes and will consist of both the X and Y coordinates in unsigned integer format.
Horizontal - If fType is Horizontal, the second point of the two-point line will be two bytes and will consist of only the X coordinate in lln~igned integer format. The Y coordinate of the second point is the same as the Y coordinate of the first point.
Vertical - If fType is Vertical, the second point of the two-point line will be two bytes and will consist of only the Y coordinate in unsigned integer format. The X coordinate of the second point is the sarne as the X coordinate of the first point.
The first point and the diagonal line second point use the unsigned integer 3 BYTE format where the rem~ining bits are defined as:
~ X coordinate (11 bits) CA 022~800~ 1998-12-09 bl3-b3 x - unsigned integer value of X coordinate.
Y coordinate (10 bits) b23-bl4 s y - unsigned integer value of Y coordinate.
The second point of horizontal or vertical lines use the 2 BYTE format where the r~ g bits are defined as:
X or Y coordinate (13 bits) bl5-b3 u - Value of X or Y coordinate in unsigned integer format.
Remarks:
If frype is Horizontal, the value sent will be the X coordinate of the second point of the line. The Y coordinate will not be sent since it is the same as the Y coordinate of the first point.
If fType is Vertical, the value sent will be the Y coordinate of the second point of the line. The X coordinate will not be sent since it is the same as the X coordinate of the first point.
T
Claims (9)
1. A method for compressing graphical line data, representative of a graphical line, transmitted from an application server over a low bandwidth communication transport mechanism to a graphical user interface of a workstation for display on a display screen of the workstation, comprising the steps of, at the application server;
(i) determining, from said graphical line data, coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path;
(ii) representing said coordinate locations as compressed coordinate location data of variable length and said attributes as a compressed attribute data of variable length; and (iii) transmitting a variable length compressed line data packet which includes said compressed coordinate location data and said compressed attribute data for each sub-path.
(i) determining, from said graphical line data, coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path;
(ii) representing said coordinate locations as compressed coordinate location data of variable length and said attributes as a compressed attribute data of variable length; and (iii) transmitting a variable length compressed line data packet which includes said compressed coordinate location data and said compressed attribute data for each sub-path.
2. The method of claim 1 further comprising the steps of, at the workstation:
(i) receiving, at a decompression program, the variable length compressed line data packet;
(ii) determining said graphical line data, from said variable length compressed line data packet, including coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path;
(iii) providing the graphical line data to the graphical user interface; and (iv) displaying said graphical line on the display screen of said workstation.
(i) receiving, at a decompression program, the variable length compressed line data packet;
(ii) determining said graphical line data, from said variable length compressed line data packet, including coordinate locations for the endpoints of each sub-path of the graphical line and attributes of each sub-path;
(iii) providing the graphical line data to the graphical user interface; and (iv) displaying said graphical line on the display screen of said workstation.
3. The method of claim 1 wherein the compressed line data packet fully defines the characteristics of the graphical line.
4. The method of claim 1 wherein said attributes include clipping, style, gaps, color and type.
5. The method of claim 4 wherein said style of each sub-path is solid, alternate, dash, dot, dashdot, dashdotdot, mask or array.
6. The method of claim 4 wherein said type of each sub-path is normal, horizontal, vertical, diagonal or ellipse.
7. The method of claim 1 further comprising before step (a) the step of:
segmenting a graphical line into at least one sub-path.
segmenting a graphical line into at least one sub-path.
8. The method of claim 7 wherein step (b) comprises determining, from said graphical line data, coordinate locations for the endpoints of each sub-path.
9. The method of claim 7 wherein step (d) comprises determining, from said graphical line data, attributes of each sub-path include clipping, style, gaps, color and type.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/662,590 US6057857A (en) | 1996-06-12 | 1996-06-12 | Method for the lossless compression of lines in a distributed computer system |
| US08/662,590 | 1996-06-12 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2258005A1 true CA2258005A1 (en) | 1997-12-18 |
Family
ID=24658344
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002258005A Abandoned CA2258005A1 (en) | 1996-06-12 | 1997-05-28 | Lossless line compression |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US6057857A (en) |
| EP (1) | EP0978100B1 (en) |
| JP (1) | JP2001510643A (en) |
| KR (1) | KR20000016611A (en) |
| AU (1) | AU714722B2 (en) |
| CA (1) | CA2258005A1 (en) |
| DE (1) | DE69707021T2 (en) |
| IL (1) | IL127513A0 (en) |
| WO (1) | WO1997048077A1 (en) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6831637B1 (en) * | 1999-12-30 | 2004-12-14 | Intel Corporation | Method and apparatus for compressing three dimensional surface data |
| US20020030843A1 (en) * | 2000-02-02 | 2002-03-14 | Tuli Raja Singh | Portable high speed internet access device |
| US20020115477A1 (en) * | 2001-02-13 | 2002-08-22 | Raja Singh | Portable high speed internet access device with scrolling |
| US7023572B2 (en) * | 2000-02-02 | 2006-04-04 | Raja Singh Tuli | Portable high speed internet access device |
| US7068381B1 (en) | 2000-02-02 | 2006-06-27 | Raja Tuli | Portable high speed internet access device |
| US6633314B1 (en) | 2000-02-02 | 2003-10-14 | Raja Tuli | Portable high speed internet device integrating cellular telephone and palm top computer |
| US7289244B2 (en) | 2000-02-02 | 2007-10-30 | Raja Singh Tuli | Portable high speed internet access device |
| US7356570B1 (en) | 2000-08-29 | 2008-04-08 | Raja Tuli | Portable high speed communication device |
| US6941382B1 (en) | 2000-02-07 | 2005-09-06 | Raja Tuli | Portable high speed internet or desktop device |
| US6874009B1 (en) | 2000-02-16 | 2005-03-29 | Raja Tuli | Portable high speed internet device with user fees |
| US20020029285A1 (en) * | 2000-05-26 | 2002-03-07 | Henry Collins | Adapting graphical data, processing activity to changing network conditions |
| US7117239B1 (en) | 2000-07-28 | 2006-10-03 | Axeda Corporation | Reporting the state of an apparatus to a remote computer |
| US7035912B2 (en) | 2000-08-28 | 2006-04-25 | Abaco.P.R., Inc. | Method and apparatus allowing a limited client device to use the full resources of a networked server |
| US7185014B1 (en) | 2000-09-22 | 2007-02-27 | Axeda Corporation | Retrieving data from a server |
| US8108543B2 (en) | 2000-09-22 | 2012-01-31 | Axeda Corporation | Retrieving data from a server |
| US7191211B2 (en) * | 2000-10-03 | 2007-03-13 | Raja Tuli | Portable high speed internet access device priority protocol |
| US6842777B1 (en) | 2000-10-03 | 2005-01-11 | Raja Singh Tuli | Methods and apparatuses for simultaneous access by multiple remote devices |
| US6915327B1 (en) | 2000-10-30 | 2005-07-05 | Raja Singh Tuli | Portable high speed communication device peripheral connectivity |
| US6928461B2 (en) | 2001-01-24 | 2005-08-09 | Raja Singh Tuli | Portable high speed internet access device with encryption |
| US7171444B2 (en) * | 2001-11-14 | 2007-01-30 | Sharp Laboratories Of America, Inc. | Remote desktop protocol compression system |
| US7254601B2 (en) | 2001-12-20 | 2007-08-07 | Questra Corporation | Method and apparatus for managing intelligent assets in a distributed environment |
| KR100422252B1 (en) * | 2001-12-20 | 2004-03-11 | 삼성전자주식회사 | Thin Client Network System and Data Transmitting Method thereof |
| WO2003075116A2 (en) | 2002-03-01 | 2003-09-12 | T5 Labs Ltd | Centralised interactive graphical application server |
| US8671213B2 (en) | 2002-03-14 | 2014-03-11 | Citrix Systems, Inc. | Methods and apparatus for generating graphical and media displays at a client |
| US7376695B2 (en) * | 2002-03-14 | 2008-05-20 | Citrix Systems, Inc. | Method and system for generating a graphical display for a remote terminal session |
| US7178149B2 (en) | 2002-04-17 | 2007-02-13 | Axeda Corporation | XML scripting of soap commands |
| US8176428B2 (en) * | 2002-12-03 | 2012-05-08 | Datawind Net Access Corporation | Portable internet access device back page cache |
| US7966418B2 (en) | 2003-02-21 | 2011-06-21 | Axeda Corporation | Establishing a virtual tunnel between two computer programs |
| EP1635269B1 (en) * | 2004-09-14 | 2020-04-15 | Microsoft Technology Licensing, LLC | Functions acting on arbitrary geometric paths |
| US7450128B2 (en) * | 2004-11-15 | 2008-11-11 | Hewlett-Packard Development Company, L.P. | Systems and methods of providing image copy and modify commands to a receiver with an associated display |
| US8171169B2 (en) * | 2005-03-14 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for updating a graphical display in a distributed processing environment |
| US8423673B2 (en) * | 2005-03-14 | 2013-04-16 | Citrix Systems, Inc. | Method and apparatus for updating a graphical display in a distributed processing environment using compression |
| US7817849B2 (en) * | 2005-08-18 | 2010-10-19 | Hewlett-Packard Development Company, L.P. | Method and apparatus for graphical data compression |
| US8370479B2 (en) | 2006-10-03 | 2013-02-05 | Axeda Acquisition Corporation | System and method for dynamically grouping devices based on present device conditions |
| US8065397B2 (en) | 2006-12-26 | 2011-11-22 | Axeda Acquisition Corporation | Managing configurations of distributed devices |
| WO2010042578A1 (en) * | 2008-10-08 | 2010-04-15 | Citrix Systems, Inc. | Systems and methods for real-time endpoint application flow control with network structure component |
Family Cites Families (52)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3596257A (en) | 1969-09-17 | 1971-07-27 | Burroughs Corp | Method and apparatus for allocating small memory spaces to a computer program |
| US4013828A (en) | 1976-02-20 | 1977-03-22 | Bell Telephone Laboratories, Incorporated | Method and arrangement for reducing the bandwidth and/or time required to transmit a dithered image |
| US4410916A (en) | 1979-08-24 | 1983-10-18 | Compression Labs, Inc. | Dual mode facsimile coding system and method |
| DE2939411C2 (en) | 1979-09-28 | 1982-09-02 | Siemens AG, 1000 Berlin und 8000 München | Data processing system with virtual memory addressing |
| US4322795A (en) | 1980-01-24 | 1982-03-30 | Honeywell Information Systems Inc. | Cache memory utilizing selective clearing and least recently used updating |
| US4463424A (en) | 1981-02-19 | 1984-07-31 | International Business Machines Corporation | Method for dynamically allocating LRU/MRU managed memory among concurrent sequential processes |
| US4562423A (en) | 1981-10-15 | 1985-12-31 | Codex Corporation | Data compression |
| US4430712A (en) | 1981-11-27 | 1984-02-07 | Storage Technology Corporation | Adaptive domain partitioning of cache memory space |
| US4503501A (en) | 1981-11-27 | 1985-03-05 | Storage Technology Corporation | Adaptive domain partitioning of cache memory space |
| US4499499A (en) | 1982-12-29 | 1985-02-12 | International Business Machines Corporation | Method for identification and compression of facsimile symbols in text processing systems |
| DE3483489D1 (en) | 1983-04-13 | 1990-12-06 | Nec Corp | MEMORY ACCESS DEVICE IN A DATA PROCESSING SYSTEM. |
| JP2785821B2 (en) | 1983-10-07 | 1998-08-13 | ソニー株式会社 | Digital signal generation circuit |
| US4779189A (en) | 1985-06-28 | 1988-10-18 | International Business Machines Corporation | Peripheral subsystem initialization method and apparatus |
| US4899149A (en) | 1986-02-28 | 1990-02-06 | Gary Kahan | Method of and apparatus for decoding Huffman or variable-length coees |
| US4862392A (en) * | 1986-03-07 | 1989-08-29 | Star Technologies, Inc. | Geometry processor for graphics display system |
| US4949281A (en) * | 1987-04-23 | 1990-08-14 | H. Berthold Ag | Method and apparatus for generating and producing two-dimensional graphic object by polynominal parametric curves |
| US4992954A (en) | 1987-08-05 | 1991-02-12 | Hitachi, Ltd. | Method of storing character patterns and character pattern utilization system |
| US4928247A (en) * | 1987-08-13 | 1990-05-22 | Digital Equipment Corporation | Method and apparatus for the continuous and asynchronous traversal and processing of graphics data structures |
| JPH01246656A (en) | 1988-03-29 | 1989-10-02 | Nec Corp | Inter-processor sharing memory control system |
| US5103303A (en) | 1988-04-19 | 1992-04-07 | Konica Corporation | Multicolor imaging forming apparatus |
| JP2790815B2 (en) * | 1988-08-10 | 1998-08-27 | 株式会社リコー | Image data compression method |
| US4905141A (en) | 1988-10-25 | 1990-02-27 | International Business Machines Corporation | Partitioned cache memory with partition look-aside table (PLAT) for early partition assignment identification |
| EP0389151A3 (en) | 1989-03-22 | 1992-06-03 | International Business Machines Corporation | System and method for partitioned cache memory management |
| US5394531A (en) | 1989-04-03 | 1995-02-28 | International Business Machines Corporation | Dynamic storage allocation system for a prioritized cache |
| KR930003126B1 (en) * | 1989-04-20 | 1993-04-19 | 가부시기가이샤 도시바 | Method and system for detemining connection states of straight short vectors |
| JP2858795B2 (en) | 1989-07-14 | 1999-02-17 | 株式会社日立製作所 | Real memory allocation method |
| US5119319A (en) * | 1989-12-14 | 1992-06-02 | Options Unlimited Research Corp. | Full-duplex video communication system |
| US5309555A (en) * | 1990-05-15 | 1994-05-03 | International Business Machines Corporation | Realtime communication of hand drawn images in a multiprogramming window environment |
| US5269003A (en) | 1990-05-24 | 1993-12-07 | Apple Computer, Inc. | Memory architecture for storing twisted pixels |
| CA2045788A1 (en) | 1990-06-29 | 1991-12-30 | Kadangode K. Ramakrishnan | Cache arrangement for file system in digital data processing system |
| JPH0799508B2 (en) | 1990-10-15 | 1995-10-25 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Method and system for dynamically partitioning cache storage |
| US5339411A (en) | 1990-12-21 | 1994-08-16 | Pitney Bowes Inc. | Method for managing allocation of memory space |
| US5315698A (en) * | 1991-08-21 | 1994-05-24 | Digital Equipment Corporation | Method and apparatus for varying command length in a computer graphics system |
| US5321806A (en) * | 1991-08-21 | 1994-06-14 | Digital Equipment Corporation | Method and apparatus for transmitting graphics command in a computer graphics system |
| CA2083634C (en) | 1991-12-30 | 1999-01-19 | Hung Ping Wong | Method and apparatus for mapping page table trees into virtual address space for address translation |
| US5351129A (en) | 1992-03-24 | 1994-09-27 | Rgb Technology D/B/A Rgb Spectrum | Video multiplexor-encoder and decoder-converter |
| WO1994002898A1 (en) | 1992-07-24 | 1994-02-03 | Microsoft Corporation | Computer method and system for allocating and freeing memory |
| WO1994003853A1 (en) * | 1992-07-29 | 1994-02-17 | Communication Intelligence Corporation | A method and apparatus for compression of electronic ink |
| JPH0659982A (en) | 1992-08-10 | 1994-03-04 | Hitachi Ltd | Method and device for controlling virtual storage |
| US5434992A (en) | 1992-09-04 | 1995-07-18 | International Business Machines Corporation | Method and means for dynamically partitioning cache into a global and data type subcache hierarchy from a real time reference trace |
| US5491808A (en) | 1992-09-30 | 1996-02-13 | Conner Peripherals, Inc. | Method for tracking memory allocation in network file server |
| US5537551A (en) | 1992-11-18 | 1996-07-16 | Denenberg; Jeffrey N. | Data compression method for use in a computerized informational and transactional network |
| US5455576A (en) | 1992-12-23 | 1995-10-03 | Hewlett Packard Corporation | Apparatus and methods for Lempel Ziv data compression with improved management of multiple dictionaries in content addressable memory |
| CA2127053C (en) * | 1993-07-02 | 2005-01-04 | Makoto Furuhashi | Method and apparatus for time-sharing cpu system bus in image generation system |
| US5473742A (en) * | 1994-02-22 | 1995-12-05 | Paragraph International | Method and apparatus for representing image data using polynomial approximation method and iterative transformation-reparametrization technique |
| US5537635A (en) | 1994-04-04 | 1996-07-16 | International Business Machines Corporation | Method and system for assignment of reclaim vectors in a partitioned cache with a virtual minimum partition size |
| US5734388A (en) * | 1994-05-16 | 1998-03-31 | Agfa Division, Bayer Corporation | Method and apparatus for data compression of digital data to produce a scaleable font database |
| US5754187A (en) * | 1994-05-16 | 1998-05-19 | Agfa Division, Bayer Corporation | Method for data compression of digital data to produce a scaleable font database |
| US5572206A (en) | 1994-07-06 | 1996-11-05 | Microsoft Corporation | Data compression method and system |
| US5566288A (en) * | 1994-09-02 | 1996-10-15 | Caterpillar Inc. | System and method for automatically fitting a B-spline curve to a set of data points |
| US5771034A (en) | 1995-01-23 | 1998-06-23 | Microsoft Corporation | Font format |
| US5651136A (en) | 1995-06-06 | 1997-07-22 | International Business Machines Corporation | System and method for increasing cache efficiency through optimized data allocation |
-
1996
- 1996-06-12 US US08/662,590 patent/US6057857A/en not_active Expired - Lifetime
-
1997
- 1997-05-28 DE DE69707021T patent/DE69707021T2/en not_active Expired - Lifetime
- 1997-05-28 KR KR1019980710207A patent/KR20000016611A/en active IP Right Grant
- 1997-05-28 JP JP50162398A patent/JP2001510643A/en active Pending
- 1997-05-28 CA CA002258005A patent/CA2258005A1/en not_active Abandoned
- 1997-05-28 WO PCT/US1997/008998 patent/WO1997048077A1/en active IP Right Grant
- 1997-05-28 AU AU32154/97A patent/AU714722B2/en not_active Expired
- 1997-05-28 IL IL12751397A patent/IL127513A0/en unknown
- 1997-05-28 EP EP97927780A patent/EP0978100B1/en not_active Expired - Lifetime
-
1999
- 1999-10-29 US US09/430,817 patent/US6172683B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6057857A (en) | 2000-05-02 |
| AU3215497A (en) | 1998-01-07 |
| KR20000016611A (en) | 2000-03-25 |
| EP0978100B1 (en) | 2001-09-26 |
| JP2001510643A (en) | 2001-07-31 |
| US6172683B1 (en) | 2001-01-09 |
| DE69707021T2 (en) | 2002-06-20 |
| DE69707021D1 (en) | 2001-10-31 |
| IL127513A0 (en) | 1999-10-28 |
| AU714722B2 (en) | 2000-01-06 |
| WO1997048077A1 (en) | 1997-12-18 |
| EP0978100A1 (en) | 2000-02-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2258005A1 (en) | Lossless line compression | |
| US6304928B1 (en) | Compressing/decompressing bitmap by performing exclusive- or operation setting differential encoding of first and previous row therewith outputting run-length encoding of row | |
| US6151020A (en) | Real time bit map capture and sharing for collaborative tools | |
| US6118899A (en) | Method for lossless bandwidth compression of a series of glyphs | |
| US7404014B2 (en) | Method and system for transmitting and determining the effects of display orders from shared application between a host and shadow computer | |
| US7076735B2 (en) | System and method for network transmission of graphical data through a distributed application | |
| AU2003220302B2 (en) | Methods and apparatus for generating graphical and media displays at a client | |
| EP2171606B1 (en) | Bitmap-based display remoting | |
| US7852342B2 (en) | Remote client graphics rendering | |
| US5915098A (en) | System for compressing bit maps to be shared and displayed in collaborative tool by client and server systems | |
| US10490157B2 (en) | Compression of distorted images for head-mounted display | |
| US8760366B2 (en) | Method and system for remote computing | |
| US20010034770A1 (en) | Method and device for implementing networked terminals in graphical operating environment | |
| CN113794899A (en) | Cloud desktop image data transmission method, device, equipment and storage medium | |
| US7711840B2 (en) | Protocol for remote visual composition | |
| JP2654749B2 (en) | Data compression method | |
| US7075538B2 (en) | Methods and apparatus for faster line drawing on remote displays | |
| AU736002B2 (en) | A method for lossless decompression | |
| EP1271409B1 (en) | Method and System for Generating a digital image including a transparent object | |
| US20020051568A1 (en) | Bitmap graphics compression for image data | |
| US7437483B1 (en) | System and method for transferring a compressed data file to a peripheral device | |
| Li et al. | FCE: A fast content expression for server-based computing | |
| CN116680021A (en) | Application window blackout frame removing method for remote desktop protocol | |
| CN113613039A (en) | Video transmission method, system, computing device and computer storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |