## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• Oct 20 2019 22:59
@dockimbel banned @SmackMacDougal
• Dec 03 2017 05:53
@PeterWAWood banned @matrixbot
• Sep 28 2016 12:19
@PeterWAWood banned @TimeSeriesLord
• Aug 13 2016 03:23
@PeterWAWood banned @Vexercizer
hiiamboris
@hiiamboris
I've come to seek your advice ☻ In case I don't see a polar bear in my kitchen...
Does it make sense to you that rotate of the Draw dialect currently rotates around 0.5x0.5 pivot? I think we should change it to 0.0x0.0 (see red/red#3504).
hiiamboris
@hiiamboris
Same question on scale
Toomas Vooglaid
@toomasv
@hiiamboris Seems correct:
im: draw 3x3 [box 0x0 2x2 pen red line 0x0 2x0 pen blue line 2x0 2x2 pen green line 2x2 0x2 pen yellow line 0x2 0x0]
view/tight  [box draw [scale 20 20 image im 0x0 2x2]]
Not only rotate and scale, but draw on first place :smile:
view/tight [box draw [scale 20 20 [
box 0x0 2x2 pen red line 0x0 2x0 pen blue line 2x0 2x2 pen green line 2x2 0x2 pen yellow line 0x2 0x0
]]]
Toomas Vooglaid
@toomasv
hiiamboris
@hiiamboris
@toomasv It does not bother you that the scaling applies around the center of the top left pixel, not around the top left corner of that pixel?
Toomas Vooglaid
@toomasv
I mean, you are correct!
hiiamboris
@hiiamboris
Oh! Okay ☺
Toomas Vooglaid
@toomasv
From the other side, as a base of calculations, center-of-pixel seems ok. Think of e.g. line-caps and width:
view/tight [box draw [transform 0x0 90 20 20 50x10 [
fill-pen orange box 0x0 2x2
pen red line-cap square line 0x0 2x0
pen blue line-cap round line 2x0 2x2
pen green line-cap flat line 2x2 0x2
pen yellow line-width .5 line 0x2 0x0
]]]
hiiamboris
@hiiamboris
I don't see how that would have affected line-caps and width... With upper left corner of the image as a pivot your command will be transform 0x0 90 20 20 40x0 instead. I think... Which is more intuitive, no? 2x2 * 20 = 40x40
You wouldn't have to manually add another 0.5x0.5 * 20x20 = 10x10
Toomas Vooglaid
@toomasv
That's true.
hiiamboris
@hiiamboris
What I really dislike about the coordinate system is that draw commands refer as 0x0 (line 0x0 ...) to the same pixel that you would later extract as image/(1x1). Simply. Annoying. ;) But I suspect this is not gonna change...
Toomas Vooglaid
@toomasv
Yeah, I have hit my head against this several times :dizzy_face:

@hiiamboris I do not find this annoying.
draw/shape draws things in all direction (e.g. view [base draw [translate 100x100 line -2x0 -50x-55]]. It make sense that you start from 0x0 and move in any direction.
images and other series first index being 1 make sense too. I mean you want to a first element -> 1st.

ps. of course it is just my opinions. You can make (and I think you have already made) a contra-argument about 0-based indexing.

hiiamboris
@hiiamboris
Well I mean the amount of extra work required to properly subtract and add and otherwise take care of the indexes, and the effort it takes to keep in mind in what expression what origin you are using is annoying ☺
That and the fact that you'll have to tell everybody who uses draw that they have two different coordinate systems - one for indexes and one for commands...
I see even more complications though. When they make a pair! of float!s, there'll be a tough choice. Will we map all integer pairs to pixel centers, like 0x0 will be the same as 0.5x0.5? Or will we let the image lie mostly in the right lower quadrant and let it extend just half a pixel to all 3 other quadrants?
I think this one deserves a REP
@hiiamboris excuse my ignorance, but what is the purpose of float-based pairs with the images/draw etc? You want to draw on exact pixel (using integers points): 42x42 not on not-precise point (using floats): 3.14x3.14.
hiiamboris
@hiiamboris
But I do want to draw on floats! I do want seamless animation, subpixel pen positioning, continuous scaling and on and on. Otherwise forget about vector graphics
Scaling is already alright though, as it's not dictated by a pair!

@hiiamboris

But I do want to draw on floats!

but you only have integers

but isn't vector scaling/rotating indifferent? Using floats you may introduce some errors.

I'm still confused but I'm not good in the graphics.

hiiamboris
@hiiamboris
My point is that you don't need float-pairs for such things.
hiiamboris
@hiiamboris
I do.
If you think you need them then I bet you have valid reasons. It's just I don't see it. I won't talk about this more because I need to read some things on such topics.
hiiamboris
@hiiamboris
@hiiamboris no
hiiamboris
@hiiamboris
I see...
BeardPower
@BeardPower
@hiiamboris Red does not support floating point pairs at the moment. Changing it could affect other parts. To make sure there are no issues with floating pairs, the team needs to discuss on that first.
hiiamboris
@hiiamboris
I understand. And will be happy to participate in the discussion ☻
BeardPower
@BeardPower
Having the origin points at the center of the pixel would be actually correct, as a pixel is dimensionless and it also is a question of sub-pixel rendering,
hiiamboris
@hiiamboris
Pixel is not dimensionless. Or I didn't get your point.
BeardPower
@BeardPower
A pixel is dimensionless because it's just a basic unit. That's why there is DPI, which is the actually defines the size of a pixel.
Having the origin point at the top left corner of a pixel and rotating it would not only result in a rotation but also in a translation.
@9214

My point is that you don't need float-pairs for such things.

In such case, can you draw an equilateral triangle using 3 line commands for me, @nedzadarek ?

hiiamboris
@hiiamboris
@BeardPower prove it.
BeardPower
@BeardPower
@nedzadarek You need floating point units because of the center of the pixels.
@9214
And store your proof on blockchain.
hiiamboris
@hiiamboris
:D :D
BeardPower
@BeardPower
@hiiamboris First, you stated something first, so it's your turn ;-)
hiiamboris
@hiiamboris
@BeardPower I've proven my point above and in the ticket mentioned.
BeardPower
@BeardPower
Anyway: rotate a pixel with the origin at the top left corner -> the pixel will move.

@BeardPower > You need floating point units because of the center of the pixels.

But you said pixels are dimensionless :|

BeardPower
@BeardPower
Because there is only ONE pixel.
There is no half-pixel, quad-pixel or 2/3 pixel.