Do Canvas Controls behave faulty when axes are scaled ?

[Heinz Hoeffken]

Do Canvas Controls behave faulty when axes are scaled ?

I'm using a canvas control of e.g. 200 by 200 physical screen pixels. To address each pixel, the User Interface library offers the structures

Point {int x, int y} and
Rectangle {int top, int left, int height, int width}
(NOTE: all elements are INTEGER)

To draw a straight line in default (unscaled) mode of the canvas I would have to address the screen dots e.g. by the sequence

Point(0,0) (1,1) (2,2) (3,3) (4,4) etc.

and all is ok, the result is a straight line with a slope of 45 deg.

Now, I tell CVI to scale the y axis by a multiplier of e.g. 4.0 by

double y_scaling = 4.0;
SetCtrlAttribute(handle, PANEL_CANVA
S, ATTR_YSCALING, y_scaling);
(note: y_scaling is DOUBLE)

To draw the same straight line as above I would have to address the same physical screen dots by the sequence

Point(0,0) (1, 0.25) (2, 0.5) (3, 0.75) (4, 1.0)

Observing the screen, the really addressed points are

(0, 0) (1, 0) (2, 0) (3, 0) (4, 4)

One can see:
a) Instead of a straight line we get a staircase line (slope 45 deg)
b) The multiplier 4.0 is really effective (5 th point)
To demonstrate the fault accuratly I've attached the example CANV_TST.ZIP

The faulty stair steps are caused by CVI applying the principle
- first truncate (INTEGER format of the 'Point' structure)
- then multiply (DOUBLE format of y_scaling)

To correct this inconsistency CVI would have to change the format of the Point and Rectangle structures from 'int' to 'double' !? Or is there another method to get a scaled 'straight line' instead a scaled 'staircase line' ??

I'm using CVI 5.5.1 - but when looking to a col
legues computer using CVI 6.0 it's the same.

Heinz Hoeffken

[Chris Matthews]

The Canvas drawing functions are designed to draw in pixel values. Since you can't draw partial pixel values (3.24), then the functions take integers. You can use the scaling to scale the drawing, but it wouldn't still be strange for us to accept doubles in these functions since in the normal unscaled case doubles are invalid. The scaling factors were designed if you didn't not want to draw at a single pixel resolution, but at a multiple pixel resolution. It seems you are trying to use them to avoid scaling decimal values for drawing.

I would recommend just multiplying your values by 4 before passing them in. If you really want to draw at a less than 4 pixel resolution, you shouldn't change the scaling to 4.

Best Regards,

Chris Matthews
National
Instruments

[Heinz Hoeffken]

Dear Chris,

CM> The Canvas drawing functions are designed to draw in pixel values.

I came to my question because I'm nearly finished two write a small language translator "From HP-Basic to CVI" (details see below).

HP-Basic and other languages, too, offer the 'window' mechanism. That means: A 'window' defines logical ranges to replace the physical x and y ranges (represented in pixels). At a first glance, the CVI statements

SetCtrlAttribute(handle, PANEL_CANVAS, ATTR_XCOORD_AT_ORIGIN, x_origin);
SetCtrlAttribute(handle, PANEL_CANVAS, ATTR_YCOORD_AT_ORIGIN, y_origin);
SetCtrlAttribute(handle, PANEL_CANVAS, ATTR_XSCALING, x_scaling);
SetCtrlAttribute(handle, PANEL_CANVAS, ATTR_YSCALING, y_scaling);

(according to 'userint.h' x_origin, y_origin, x_scaling, y_scaling are DOUBLE)

seems to offer this kind of transformation with Canvas Controls: If you send the above 4 parameters to CVI, CVI is going to automatically shift the origin and the scaling of the axis, but, alas, there is an inconsistency with CVI: when e.g. declaring a scaling multiplier of 1.0 (the default) 100 % of the physical pixels are addressable, but with scaling = 2.0, only 50% are addressable (with 4.0 only 25 % etc). The reason is:

a) in the moment, CVI first truncates the fractional values of a logical (window) point (by use of the 'Point(int, int)' structure)
b) then CVI applies the previously submitted user offsets and multipliers (x_origin, y_origin, x_scaling, y_scaling) to automatically transform the logical points to physical pixels.

Instead of '1st truncate, then multiply' the reverse sequence is correct:

1) first multiply the user's fractional window coordinate values (in DOUBLE) by applying 'window' parameters (x_origin, y_origin, x_scaling, y_scaling - in DOUBLE)
2) then truncate the result (still in DOUBLE) to INTEGER to get the physical pixel coordinates

Could you discuss this with your CVI development staff?

You may say, instead of perfectly windowing canvas controls one could use the graph controls for windowing. However, graph controls involve a lot of internal automatism and prevent the user to pre-determine all details of the final graphical pixels.

Heinz Hoeffken

Some comments to HP-Basic:

In the seventies, Hewlett Packard invented the HP-IB-Bus as a predecessor of the today's NI 488.2 GPIB bus. And in the 70-ies we began to do automated measurements by using HP calculators and HP instruments connected by the HPIB-Bus. Beginning of the eighties, HP-calculators were the state of the art in industry as well as at universities etc. The calculators had a powerful software dialect named HP-Basic (Rocky Mountain Basic) with perfect GPIB implementation. It was IBM and the PC's who caused HP to draw it's HP-Basic calculators from the market. However, in 1988 the American Transera Corp. had adapted the HP-Basic to MS-DOS PC's and sold it as HT-BASIC. Lots of engineers exchanged their HP computers by PC's and continued to use the old well proven HP-Basic measurement programs on PCs with HT-Basic. This was so successful that when MS-Windows came, Hewlett Packard and Transera issued a common "HP-BASIC for Windows" which today is still a little bit on the market.

To summarize:

The factory I'm working with is planning to replace HP-GPIB cards by National Instruments NI-GPIB 488.2 cards and to purchase new LabWindows CVI licenses. We have lots of programs in HP-BASIC to control lots of ATE measurement instruments. I myself am fit in HP-Basic as well as in CVI programming (CVI license owner since 4.5 years), but some of my colleagues still are writing in HP-Basic and are beginners with CVI. That's why I've written a CVI library to allow to type function calls into the CVI editor looking similar to 'HP-Basic syntax'. - The WINDOW statement is one which still makes trouble as discussed above.