|
www.riscos.com Technical Support: |
The Draw module is an implementation of PostScript type drawing. A collection of moves, lines, and curves in a user-defined coordinate system are grouped together and can be manipulated as one object, called a path.
A path can be manipulated in memory or upon writing to the VDU. There is full control over the following characteristics of the path:
A path can be displayed in many different ways. For example, if you write a path that draws a petal, and draw it several times rotating about a point, you will have a flower. This uses only one of the characteristics that you can control.
The Draw application was written using this module, and this is the kind of application that it is suited to. It is advisable to read the section on Draw in the User Guide to familiarise yourself with some of the properties of the Draw module.
There are many specialised terms used within the Draw module. Here are the most important ones. If you are familiar with PostScript, then many of these should be the same.
This is an area where you must take great care when using the Draw module, because four different systems are used in different places.
OS units are notionally 1/180th of an inch, and are the standard units used by the VDU drivers for specifying output to the screen.
This coordinate system is (not surprisingly) what the Draw module uses when it strokes a path onto the screen.
Internally, Draw uses a coordinate system the units of which are 1/256th of an OS unit. We shall call these internal Draw units.
In a 32 bit internal Draw number, the top 24 bits are the number of OS units, and the bottom 8 bits are the fraction of an OS unit.
The coordinates used in a path can be in any units that you wish to use. These are converted by the transformation matrix into internal Draw units when generating output.
Note that because it is a fixed point system, scaling problems can occur if the user units differ too much from the internal Draw units. Because of this problem, you are limited in the range of user units that you can use.
Transform units are only used to specify some numbers in the transformation matrix. They divide a word into two parts: the top two bytes are the integer part, and the bottom two bytes are the fraction part.
This is a three by three matrix that can be used to rotate, scale or translate a path in a single operation. It is laid out like this:
| a | b | 0 |
| c | d | 0 |
| e | f | 1 |
This matrix transforms a coordinate (x, y) into another coordinate (x', y') as follows:
x' = ax + cy + e
y' = bx + dy + f
The common transformations can all be easily done with this matrix. Translation by a given displacement is done by e for the x axis and f for the y axis. Scaling the x axis uses a, while the y axis uses d. Rotation can be performed by setting a = cos(![[THETA]](../symbols/entities/952.png)
)_ B = SIN()_ C = -SIN() AND D = COS()_ WHERE is the angle of rotation.
a, b, c and d are given in transform units to allow accurate specification of the fractional part. e and f are specified in internal Draw units, so that the integer part can be large enough to adequately specify displacements on the screen. (Were transform units to be used for these coefficients, then the maximum displacement would only be 256 OS units, which is not very far on the screen.)
The winding rule determines what the Draw module considers to be interior, and hence filled.
Even-odd means that an area is filled if a ray from that area to outside the path's bounding box crosses an odd number of paths.
Non-zero winding fills areas on the basis of the direction in which the subpaths which surround the area were constructed. If an equal number of subpaths in each direction surround the area, it is not filled, otherwise it is.
The positive winding rule will fill an area if it is surrounded by more anti-clockwise subpaths than clockwise. The negative winding rule works in reverse to this.
Even-odd and non-zero winding are printer driver compatible, whereas the other two are not. If you wish to use the path with a printer driver, then bear this in mind.
Flattening means bisecting any Bezier curves recursively until each of the resulting small lines lies within a specified distance of the curve. This distance is called flatness. The longer this distance, the more obvious will be the straight lines that approximate the curve.
All moving and drawing is relative to the VDU graphics origin (as set by VDU 29,x;y; ).
None of the Draw SWIs will plot outside the boundaries of the VDU graphics window (as set by VDU 24,l;b;r;t; ).
All calls use the colour (both pixel pattern and operation) set up for the VDU driver. Note that not all such colours are compatible with printer drivers.
If your program needs to generate printer output, then it is very important that you read the chapter entitled Printer Drivers. The Draw SWIs that are affected by printing have comments in them about the limitations and effects.
SWI numbers and names have been allocated to support floating point Draw operations. In fact for every SWI described in this chapter, there is an equivalent one for floating point - just add FP to the end of each name.
The floating point numbers used in the specification are IEEE single precision floating point numbers.
They may be supported in some future version of RISC OS, but if you try to use them in current versions you'll get an error back.
Many common structures are used by Draw module SWIs. Rather than duplicate the descriptions of these in each SWI, they are given here. Some SWIs have small variations which are described with the SWI.
The path structure is a sequence of subpaths, each of which is a sequence of elements. Each element is from one to seven words in length. The lower byte of the first word is the element type. The remaining three bytes of it are free for client use. On output to the input path the Draw module will leave these bytes unchanged. However, on output to a standard output path the Draw module will store zeroes in these three bytes.
The element type is a number from 0 to 8 that is followed by the parameters for the element, each a word long. The path elements are as follows:
You will notice that there are some order constraints on these element types:
When you are stroking (using Draw_Stroke), if a subpath ends with a 4 or 5 then it is closed, and the ends are joined - whereas a 2 or 3 leaves a subpath open, and the loose ends are capped. These four path elements explicitly leave a stroked subpath either open or closed.
Some other operations implicitly close open subpaths, and this will be stated in their descriptions.
Just because the ends of a subpath have the same coordinates, that doesn't mean the subpath is closed. There is no reason why the loose ends of an open subpath cannot be coincident.
After a SWI has written to an output path, it is identical to an input path. When it is first passed to the SWI as a parameter, the start of the block pointed to should contain an element type zero (end of path) followed by the number of available bytes. This is so that the Draw module will not accidentally overrun the buffer.
The fill style is a word that is passed in a call to Draw_Fill, Draw_Stroke, Draw_StrokePath or Draw_ProcessPath. It is a bitfield, and all of the calls use at least the following common states. See the description of each call for differences from this:
| Bit(s) | Value | Meaning |
|---|---|---|
| 0, 1 | 0 | non-zero winding number rule. |
| 1 | negative winding number rule. | |
| 2 | even-odd winding number rule. | |
| 3 | positive winding number rule. | |
| 2 | 0 | don't plot non-boundary exterior pixels. |
| 1 | plot non-boundary exterior pixels. | |
| 3 | 0 | don't plot boundary exterior pixels. |
| 1 | plot boundary exterior pixels. | |
| 4 | 0 | don't plot boundary interior pixels. |
| 1 | plot boundary interior pixels. | |
| 5 | 0 | don't plot non-boundary interior pixels. |
| 1 | plot non-boundary interior pixels. | |
| 6 - 31 | reserved - must be written as zero |
The matrix is passed as pointer to a six word block, in the order a, b, c, d, e, and f as described earlier. That is:
| Offset | Value | Common use(s) |
|---|---|---|
| 0 | a | x scale factor, or cos() TO rotate
|
| 4 | b | sin() to rotate
|
| 8 | c | -sin() to rotate
|
| 12 | d | y scale factor, or cos() to rotate
|
| 16 | e | x translation |
| 20 | f | y translation |
If the pointer is zero, then the identity matrix is assumed - no transformation takes place.
Remember that a - d are in Transform units, while e and f are in internal Draw units; for example plotting with a scale factor of 1 - which is &1000 Transform units - and with a translation of (64, 32) - which are respectively &4000 and &2000 internal Draw units - would use the values [&1000, 0, 0, &1000, &4000, &2000].
Flatness is the maximum distance that a line is allowed to be from a Bezier curve when flattening it. It is expressed in user units. So a smaller flatness will result in a more accurate rendering of the curve, but take more time and space. For very small values of flatness, it is possible to cause the 'No room in RMA' error.
A recommended range for flatness is between half and one pixel. Any less than this and you're wasting time; any more than this and the curve becomes noticeably jagged. A good starting point is:
A value of zero will use the default flatness. This is set to a useful value that balances speed and accuracy when stroking to the VDU using the default scaling.
Note that if you are going to send a path to a high resolution printer, then you may have to set a smaller flatness to avoid jagged curves.
The line thickness is in user coordinates.
The cap and join styles are each passed as a pointer to a four word block. A pointer of zero can be passed if cap and join are ignored (as they are for zero thickness lines). The block is structured as follows:
| Word | Byte | Description |
|---|---|---|
| 0 | 0 | join style
|
| 1 | leading cap style
| |
| 2 | trailing cap style (as leading cap style) | |
| 3 | reserved - must be written as zero. | |
| 4 | This value must be set if using mitred joins. | |
| 0,1 | fractional part of mitre limit for mitre joins | |
| 2,3 | integer part of mitre limit for mitre joins | |
| 8 | 0,1 | setting for leading triangular cap width on each side(in 256ths of line widths, so &0100 is 1 linewidth) |
| 2,3 | setting for leading triangular cap length away from the line, in the same measurements as above | |
| 12 | all | This sets the trailing triangular cap size, using the same structure as the previous word. |
The mitre limit is a little more complex than the others, so it is explained here rather than above. At any given corner, the mitre length is the distance from the point at which the inner edges of the stroke meet, to the point where the outer edges of the stroke meet. This distance increases as the angle between the lines decreases. If the ratio of the mitre length to the line width exceeds the mitre limit, stroke treats the corner with a bevel join instead of a mitre join. Also see the notes on scaling, later in this section.
Under RISC OS 2, the mitre limit is treated as unsigned. It is now treated as signed, but must be positive (ie 
&7FFFFFFF).
Note that words at offsets 4, 8, and 12 are only used if the appropriate style is selected by the earlier parts. The structure can therefore be made shorter if triangular caps and mitres are not used.
The dash pattern is passed as a pointer to a block, the size of which is defined at the start, as follows:
| Word | Description |
|---|---|
| 0 | distance into dash pattern to start in user coordinates |
| 4 | number of elements (n) in the dash pattern |
| 8 - 4n+4 | elements in the dash pattern, each of which is a distance in user coordinates. |
Again the pointer can be zero, which implies that continuous lines are drawn.
Each element specifies a distance to draw in the present state. The pattern starts with the draw on, and alternates off and on for each successive element. If it reaches the end of the pattern while drawing the line, then it will restart at the beginning.
If n is odd, then the elements will alternate on or off with each pass through the pattern: so the first element will be on the first pass, off the second pass, on the third pass, and so on.
The Draw module uses fixed point arithmetic for speed. The number representations used are chosen to keep rounding errors small enough not to be noticeable.
However, if you use the transformation matrix to scale a path up a great deal, you will also scale up the rounding errors and make them visible.
To avoid such problems, we recommend that you don't use scale factors of more than 8 when converting from User units to internal Draw units. (This maximum recommended scale factor of 8 is &80000 in the Transform units used in the transformation matrix.)
Though there are a number of SWIs, they all call Draw_ProcessPath. Because this takes so many parameters, the other SWIs are provided as an easy way of using its functionality.
There are two that output to the VDU. Draw_Stroke emulates the PostScript stroke function and will draw a path onto the VDU. Draw_Fill acts like the fill function and fills the inside of a path. It is likely that most applications will only use these two SWIs.
The others are shortcuts for processing a path in one way or other. Draw_StrokePath acts exactly like Draw_Stroke, except it puts its output into a path rather than onto the VDU. Filling its output path produces the same results as stroking its input path. Draw_FlattenPath will handle only the flattening of a path, writing its output to a path. Likewise, Draw_TransformPath will only use the matrix on a path. All these processing SWIs are useful when a path will be sent to the VDU many times. If the path is flattened or transformed before the stroking, then it will be done faster.
If you are using a printer driver, you should note that it cannot deal with all calls to the Draw module. For full details of this, see the chapter entitled Printer Drivers. As a general rule, you should avoid the following features:
The printer driver will also intercept DrawV and modify how parts of the Draw module work. Here is a list of the effects that are common to all the SWIs that output to the VDU normally:
R0 = pointer to input path buffer (see below)
R1 = fill style
R2 = pointer to transformation matrix, or 0 for identity matrix
R3 = flatness, or 0 for default
R4 = line thickness, or 0 for default
R5 = pointer to line cap and join specification (if required)
R6 = pointer to dash pattern, or 0 for no dashes
R7 = pointer to output path buffer, or value (see below)
R0 depends on entry value of R7
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
All the other SWIs in the Draw module are converted into calls to this SWI. They are provided to ensure that suitable names exist for common operations and to reduce the number of registers to set up when calling.
The input path, matrix, flatness, line thickness, cap and join, and dash pattern are as specified in the Data structures.
The fill style is as on Fill style, with the following additions:
| Bit(s) | Meaning |
|---|---|
| 6 - 26 | reserved - must be written as zero |
| 27 | set if open subpaths are to be closed |
| 28 | set if the path is to be flattened |
| 29 | set if the path is to be thickened |
| 30 | set if the path is to be re-flattened after thickening |
| 31 | set for floating point output (not implemented) |
Normally, the output path will act as described on Output path, but with the following changes if the following values are passed in R7:
| Value | Meaning |
|---|---|
| 0 | Output to the input path buffer. Only valid if the input path's length (ie storage requirement) does not change during the call, such as when doing a transformation only. |
| 1 | Fill the path normally. |
| 2 | Fill the path, subpath by subpath. (Draw_Stroke will often use this to economise on RMA usage). |
| 3 | Count how large an output buffer is required for the given path and actions. |
| &80000000+pointer | Output the path's bounding box, in transformed coordinates. The buffer will contain the four words: low x, low y, high x, high y. |
| pointer | Output to a specified output buffer. |
| The length of the buffer must be indicated by putting a suitable path element 0 at the start of the buffer, and a pointer to the new path element 0 is returned in R0 to allow you to append to the output path. | |
You may do the following things with this call, in this order:
![[NOT EQUAL]](../symbols/entities/8800.png)
0).
0).
Note that R3, R4 and R5 may be left unspecified if the options that use them are not specified.
If you try dashing, thickening or filling on an unflattened Bezier curve, it will produce an error, as this is not allowed.
If you are using the printer driver, then it will intercept this SWI and affect its operation. In addition to the general comments in the chapter entitled Printer drivers, it is unable to handle R7 = 1 or 2.
None
Process a path and send to VDU, filling the interior portion
R0 = pointer to input path
R1 = fill style, or 0 for default
R2 = pointer to transformation matrix, or 0 for identity matrix
R3 = flatness, or 0 for default
R0 corrupted
R1 - R3 preserved
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
This command emulates the PostScript 'fill' operator. It performs the following actions:
The input path, matrix, and flatness are as specified in the Data structures.
The fill style is as specified on Fill style with the following addition. A fill style of zero is a special case. It specifies a useful default fill style, namely &30. This means fill to halfway through boundary, non-zero rule.
If you are using the printer driver, then it will intercept this SWI and affect its operation. See the general comments in the Printer drivers.
None
R0 = pointer to input path
R1 = fill style, or 0 for default (see below)
R2 = pointer to transformation matrix, or 0 for identity matrix
R3 = flatness, or 0 for default
R4 = line thickness, or 0 for default
R5 = pointer to line cap and join specification (if required)
R6 = pointer to dash pattern, or 0 for no dashes
R0 corrupted
R1 - R6 preserved
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
This command emulates the PostScript 'stroke' operator. It performs the following actions:
0
The input path, matrix, flatness, cap and join, and dash pattern are as specified in the Data structures.
The fill style is as specified on Fill style with the following additions. A fill style of zero is a special case. If the line thickness in R4 is non-zero, then it means &30, as in Draw_Fill. If R4 is zero, then &18 is the default, as the flattened and thickened path will have no interior in this case.
If the top bit of the fill style is set, this makes the Draw module plot the stroke all at once rather than one subpath at a time. This means the code will never double plot a pixel, but uses up much more temporary work-space.
The line thickness is as on Line thickness, with the following added restrictions. If the specified thickness is zero, Draw cannot deal with filling non-boundary exterior pixels and not filling boundary exterior pixels at the same time, ie fill bits 3 - 2 being 01. If the specified thickness is non-zero, Draw cannot deal with filling just the boundary pixels, ie fill bits 5 - 2 being 0110.
If you are using the printer driver, then it will intercept this SWI and affect its operation. In addition to the general comments in the Printer drivers, you should also be aware that most printer drivers will not pay any attention to bit 31 of the fill style - ie plot subpath by subpath or all at once (see above). Use Draw_ProcessPath to get around this problem by processing it before stroking.
DrawV
Like Draw_Stroke, except writes its output to a path
R0 = pointer to input path
R1 = pointer to output path, or 0 to calculate output buffer size
R2 = pointer to transformation matrix, or 0 for identity matrix
R3 = flatness, or 0 for default
R4 = line thickness, or 0 for default
R5 = pointer to line cap and join specification
R6 = pointer to dash pattern, or 0 for no dashes
R0 depends on entry value of R1
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
The input and output paths, matrix, flatness, line thickness, cap and join, and dash pattern are as specified in the Data structures.
This call acts exactly like a call to Draw_Stroke, except that it doesn't write its output to the VDU, but to an output path.
DrawV
R0 = pointer to input path
R1 = pointer to output path, or 0 to calculate output buffer size
R2 = flatness, or 0 for default
R0 depends on entry value of R1
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
The input and output paths, and flatness are as specified in the Data structures.
This call acts like a subset of Draw_StrokePath. It will only flatten a path. This would be useful if you wanted to stroke a path multiple times and didn't want the speed penalty of flattening the path every time.
R0 = pointer to input path
R1 = pointer to output path, or 0 to overwrite the input path
R2 = pointer to transformation matrix, or 0 for identity matrix
R3 = 0
R0 depends on entry value of R1
Interrupts are enabled
Fast interrupts are enabled
Processor is in SVC mode
SWI is not re-entrant
The input and output paths, and matrix are as specified in the Data structures.
This call acts like a subset of Draw_StrokePath. It will only transform a path. This would be useful if you wanted to stroke a path multiple times and didn't want the speed penalty of transforming the path every time. It is also useful if you want to transform a path before dashing, thickening and so on, to avoid having the rounding errors from the latter operations magnified by the transformation.
The test program that is shown here was devised to represent millimetres internally and scale them to be the correct size when drawn on a particular monitor. Because monitors are different sizes, and even the same model can be adjusted differently in terms of vertical and horizontal picture size, this example would have to be adjusted to suit your particular setup.
This example also has a restriction on screen modes. It will only work on one where the screen is 1280 OS units by 1024 OS units - which most of the current modes are (but not, for example, 132 column modes). This corresponds to 327680 internal Draw units by 262144 internal Draw units.
The first thing to do is to fill the screen with a colour and measure the horizontal and vertical size in millimetres. For this test, the display area measured 210mm across by 160mm down.
Because of scaling limitations, we will work with a user scale of thousandths of millimetres. Thus, there are 210000 user units across and 160000 user units down.
The BASIC program described here is presented in a jumbled order so that the features are described and written one at a time. Once it is all typed in, then it will seem a lot more obvious.
The next step is to work out the scaling factors for the transformation matrix. Taking the horizontal size first, we start with 327680 internal Draw units = 210000 user units, giving 1.5604 internal Draw units per user unit. Vertically, 262144 internal Draw units = 160000 user units, giving 1.6384 internal Draw units per user unit.
These figures must now be converted to the Transform units used for scaling in the transformation matrix. The 32 bit Transform number is 216 times the actual value, since its fractional part is 16 bits long. So horizontally we want 216 × 1.5604, which is 102261 (&18F75), and vertically we want 216 × 1.6384, which is 107374 (&1A36E).
The transformation matrix is initialised as follows:
| &00018F75 | 0 | 0 |
| 0 | &0001A36E | 0 |
| 0 | 0 | 1 |
This could be calculated automatically, using the following BASIC code, which, whilst not the most efficient, is hopefully the clearest way of representing it:
30 xsize = 210000 : ysize = 160000 40 xscale% = (1280 * 256 / xsize) * &010000 50 yscale% = (1024 * 256 / ysize) * &010000
After this, xscale% would be &00018F75 and yscale% would be &0001A36E, the values to place in the matrix. The matrix would be programmed as follows:
20 DIM transform% 23 60 transform%!0 = xscale% :REM element a in the matrix 70 transform%!4 = 0 :REM element b 80 transform%!8 = 0 :REM element c 90 transform%!12 = yscale% :REM element d 100 transform%!16 = 0 :REM element e 110 transform%!20 = 0 :REM element f
It is important to remember that, whilst this example is using thousandths of millimetres as its internal coordinate system, they could be anything within the valid limits. Draw is not affected by what they are. Using the technique described above, any valid units can be used. We used 210000 by 160000 user units for our scale; it could be 500000 by 350000 or 654363 by 314159 or whatever. This program will work with all valid scales, simply by changing the definitions of xsize and ysize.
In order to create the path, this simple program uses a procedure to put a single word into the path and advance the pointer. In a large application, it would be a good idea to write individual routines to generate each element type, because this technique would become tedious in a large program.
This preamble defines what needs to be at the start of the program. Notice that line 20 overwrites the earlier definition.
10 pathlength% = 256 20 DIM path% pathlength% - 1, transform% 23 160 pathptr% = 0 :REM Initialise the pointer
Later on in the program would be the procedure to add a word to the path:
320 END 330 DEF PROCadd(value%) 340 IF pathptr%+4 > pathlength% THEN ERROR 0,"Insufficient path buffer" 350 path%!pathptr% = value% 360 pathptr% += 4 370 ENDPROC
The simple path shown here generates a rectangle with no bottom line. It is 90mm by 40mm and offset by 80mm in the x and y axes from the origin.
170 PROCadd(2) : PROCadd(80000) : PROCadd(80000) :REM Move to start 180 PROCadd(8) : PROCadd(80000) : PROCadd(120000) :REM Draw 190 PROCadd(8) : PROCadd(170000) : PROCadd(120000) 200 PROCadd(8) : PROCadd(170000) : PROCadd(80000) 250 PROCadd(4) : REM Close the subpath. PROCadd(5) would close the rectangle 260 PROCadd(0) : PROCadd(pathlength%-pathptr%-4) :REM End path
Once the path and the transformation matrix have been completed, all that remains is to set the graphics origin and stroke the path onto the screen.
270 VDU 29,0;0;
280 SYS "Draw_Stroke",path%,0,transform%,0,0,0,0
Another matrix operation that can be performed is translation, or moving. Remember that the parameters in the matrix are in internal Draw coordinates, not the millimetres used in this example as user coordinates. If you want to translate in OS coordinates, then the translation must be multiplied by 256.
In this example, we are going to re-stroke the path, translated 60 OS units in x and -100 OS units in y.
290 transform%!16 = 60<<8 300 transform%!20 = -100<<8 310 SYS "Draw_Stroke",path%,0,transform%,0,0,0,0
You will now see two versions of the path, the new one 100 OS units lower and 60 OS units shifted to the right.
Similarly, the matrix may be modified to rotate the path. If you aren't sure how to do this, then see any mathematical text on matrix arithmetic.
In order to add a curve to the path, we will add a new subpath to the section that creates the path. This curve draws an alpha shape. Note that element type 2 implicitly closes the initial subpath:
210 PROCadd(2) : PROCadd(50000) : PROCadd(50000) :REM x1, y1 220 PROCadd(6) : PROCadd(80000) : PROCadd(80000) :REM x2, y2 230 PROCadd(85000) : PROCadd(30000) :REM x3, y3 240 PROCadd(50000) : PROCadd(60000) :REM x4, y4
Whilst the flatness can be left at its default value, this shows how the stroke commands can be changed to set the flatness to a sensible value. 640 is used because this program was run in a 640 pixel mode.
280 SYS "Draw_Stroke",path%,0,transform%,xsize/640,0,0,0 310 SYS "Draw_Stroke",path%,0,transform%,xsize/640,0,0,0
To make the lines shown thicker than the default, it is necessary to specify a thickness and also the joins and caps block. Notice that line 20 has been changed to allocate space for the joins and caps block. We will use round caps and bevelled joints.
20 DIM path% pathlength%-1, transform% 23, joinsandcaps% 15 120 joinsandcaps%!0 = &010102 130 joinsandcaps%!4 = 0 140 joinsandcaps%!8 = 0 150 joinsandcaps%!12 = 0
Now all that remains is to change the stroke commands to specify a thickness and point to the block just specified. For this example we will make the first stroke 5000 units (5mm) thick and the second one half that:
280 SYS "Draw_Stroke",path%,0,transform%,xsize/640, 5000,joinsandcaps%,0 310 SYS "Draw_Stroke",path%,0,transform%,xsize/640, 2500,joinsandcaps%,0
Plainly, there are many more features that could be added to this program. But you should have the idea now of how it fits together and be able to experiment for yourself.