LiveCode Forums.

You mentioned there are more pixels on a high-res screen than there are coordinates to describe them.

That sounds like a very odd claim.

dunbarx wrote: Mon Sep 23, 2024 4:38 pm Anyway, if that is so, then what are the "effective points"? Simply as many of the "accessible" screen points as can be delineated along a bezier, with many actually drawn points being skipped over in the description of that path?

And that path is hidden from us?

Craig

I think the point is that the ovals don't have coordinate points, they are generated in a different way and the effective points of an oval is a crude approximation - hence "jaggies". All of this is fine with straight lines, but for a true curve the effective points unfortunately doesn't seem to cut it.

Having looked into SVG it's extremely laconic but actually kinda makes sense once you get round to the fact that 'commands' and single letters:
"M" sets the start coordinate.
"L" is a line (ie diagonal line)hat takes start and end coordinates
"H" is a horizontal line that takes start and end coordinates
"V" is a vertical line that takes start and end coordinates
"Q" is a quadratic Bézier curve that takes 3 paremeters - 3 sets of coordinates for start/vertex/end and a radius can be used to define this.
"Z" terminates the path

Knowing the height and width of a target shape, I can start with 0,0 and express coordinates in context of the height/width, and just use these tools to draw the shape I want and end again at 0,0, ending up with the shape I want. Assigning the path to an SVG icon's iconPath property generates an SVG that is fully scalable with no jaggies.

I've got more fine-tuning to do but will post some code as I'm finding this a useful addition.
I've only spent a few short hours on this but will, if time permits, get more into SVG and consider using drawingSvgCompile instead as this would give greater flexibility. But time is inevitably, ever shorter... and an SVG path used with an SVG icon widget seems like low-hanging fruit...

If you zoom in you still get jaggies.

Well, surprise, surprise . . .

LiveCode cannot really manage Bezier curves . . .
- - -
Jiggy-jaggy-joggy as has points.

richmond62 wrote: Mon Sep 23, 2024 5:25 pm

If you zoom in you still get jaggies.

Well, surprise, surprise . . .

LiveCode cannot really manage Bezier curves . . .

Not only is this post entirely unhelpful, it is not fully correct: You can generate curves with an oval tool and you can do this in LCB.
The point of this thread was asking if there is any way to do this for a non-oval-only shape within LC proper, or if there is a workaround.

The only workaround I've found so far is using SVG paths. It's not 'proper' LiveCode, but I can write handlers to generate the shapes and modifications I want using 'proper' LiveCode. So that's good enough for me.

I can't imagine that any of this was a surprise to anyone who read this thread...

Just so:

"Pure" LiveCode cannot manage Bezier curves: you have recourse to LCB to do this.

dunbarx wrote: Mon Sep 23, 2024 4:38 pm You mentioned there are more pixels on a high-res screen than there are coordinates to describe them. In other words, there are real physical screen pixels that cannot be described with an "x,y" description, where both "x" and "y" are integers. That a small black dot can be placed on such pixels by the engine, but such a pixel cannot be described by two integers. It seems odd to me that an actual physical LED triple can exist that way, and the engine has more information about such pixels than we do. How do it know?

I believe it has to do with the screen resolution, which can be almost anything depending on the device, particularly on mobile. For consistency, LC translates screen pixels to standard measurements based on (I think) 72 dpi or maybe 96 dpi on Windows. Without translation you'd have to script every dimension and position yourself dynamically based on the resolution of the current device. That is, "100, 100" might be an inch down and right on a low resolution computer but only a fraction of an inch on a high resolution display.

Without that translation, positioning or moving objects would be a whole lot more work.

Jacque.

For consistency, LC translates screen pixels to standard measurements based on (I think) 72 dpi or maybe 96 dpi on Windows.

I get that, and it makes sense. But it seems that a simple property that scales the current screen resolution should be available if desired.

You imply that such a thing already exists, of course. But my issue is that somehow there should be access within LC to use the "finer" pixels. They are "gettable", otherwise Stam would not have seen the smooth curve in his original post, and these SVG gadgets would not render as nicely as they probably do.

So is the presentation of a nice smooth curve being rendered outside of LC, by the underlying OS? If so, I get that too, and too bad...

Craig

dunbarx wrote: Tue Sep 24, 2024 11:03 pm But it seems that a simple property that scales the current screen resolution should be available if desired.

You imply that such a thing already exists, of course. But my issue is that somehow there should be access within LC to use the "finer" pixels.

We have scalefactor to adjust the entire stack window on any device. For iOS there's iphoneUseDeviceResolution which might be relevant but I've never tried it. For all OSs we have usePixelScaling but I haven't used that one either.

Jacque.

...we have usePixelScaling

I have never used those either; I never need to render for "artistic" purposes. But reading the several related properties, it does not seem that one can increase what LC seems to insist to use (is capable of using?) as opposed to what the screen may offer. I had hoped there was a way to do that.

Craig