Math, inclusivity and exclusivity

[museun]

Currently, the whole math library is kind of .. confusing.

There should only be 1 representation: exclusive. All rects should inclusively ranged.

The only place where exclusivity matters is on the terminal surface. this can just add Vec2::splat(1) to make it inclusive at the very end of the 'pipeline'.

But, perhaps we should make everything exclusive and the surface subtracts Vec2::splat(1).

For example, currently everything uses the exclusive ranges:

for y in 0..rect.height() {
    for x in 0..rect.width() {
        let pos = pos2(x, y); 
    }
}

But things like Rect::clamp() uses an inclusive range:

    pub fn clamp(&self, pos: Pos2) -> Pos2 {
        pos.clamp(self.min, self.max)
    }

This is a bit annoying, for example:

    fn event(&mut self, event: ViewEvent, ctx: EventCtx) -> Handled {
        if let ViewEvent::MouseDrag {
            current,
            inside: true,
            ..
        } = event
        {
            self.cursor = ctx.rect().clamp(current);
            return Handled::Sink;
        }
        Handled::Bubble
    }

That clamps the cursor to 1,1 past the viewable area of the rectangle.

I think all rectangle math should be exclusive so it aligns with how we can iterate through the coordinates of a rect.

[Samzyre]

Inclusive lower bound and exclusive upper bound is the way to go, that way it will be consistent how range math works. Also, every "pixel" or "cell" within the rects can be thought as points more easily, since rects go from [min -> max[ and a rect with sides lengths n x m would contain n x m points.

[museun]

If we settle of exclusive upperbounds then the only 'meaningful' changes would be to subtract 1 from each axis for coordinates and rectangles that touch the surface.

The surface has to be inclusive because cells have a width of 1 column, so it'd have to be: 0..w

As long as everything agrees on their upper bounds, the surface can fix it up.

Another question, should Render rects be localized? With exclusive bounds a view can just draw with:

• rect.top()..=rect.bottom();
• rect.left()..=rect.right();

and if they need to do an offset, they can just take rect.left_top() to apply to their calculations

but with exclusive bounds, rect.right() - rect.left() == rect.width() which is 1 past the end of the the actual size.

By using absolute positioning, the state updates would be trivial from event -> layout -> draw because everything is absolute (relative to the root origin of 0,0)

[museun]

A note, though. in layout set_position would be relative to the top-left of the current rect -- because the current rect doesn't actually know where its at until the resolve step after everything has been laid out.

So that method should probably be called offset()

[museun]

Currently most of the math is exclusive besides stuff like lerp / inverse_lerp / remap and such.

[Samzyre]

Having access to absolute coordinates, as well as local offset would be useful, currently drawing something in absolute coordinates such as at mouse event positions is somewhat annoying.

As for rendering bounds, it should use rect.top()..rect.bottom() and rect.left()..rect.right() as much as possible in integer space, then rect.right() - rect.left() == rect.width() is correct. For other mathy stuff that uses floating points it makes sense to keep it inclusive like 0.0..=1.0, which can be mapped to [min, max[ integer space if needed.

[museun]

The float stuff (Size, Space) aren't really meant to be iterated upon. They are generally considered constraints and not dimensions.

As for absolute vs relative: we need to pick a default and then provide helper/scoped functions for the other address space.

[Samzyre]

Absolute default makes sense, imo. It does add some responsibility for the draw step to actually draw in the designated area, but it would also let you use the full screen space, should you need it. (Would this make patch* redundant?)

[museun]

No. Patch lets you change something that's already been drawn. For example in text input it patches the cell to draw the block cursor after the text has been drawn.

The render still wouldn't let you draw outside of your rect. It'd just not translate by the texts top left any more

[Samzyre]

That makes sense, it'd still be useful to have the real coordinates, even if you cannot draw outside the area. Though, would that be somewhat surprising?

With the relative system you'd have to keep track of (or compute from the tree) the addative offset of views to the origin, whereas with absolute you already have all the information in the rect.

[museun]

Another idea is to make the rect from layout just be a size and relativize the cursor position to your previous origin.

The downside to this is you won't know if your view has moved -- just that it changed size.

To make the renderer absolute its simply not doing the offset math internally.

If the render rect were to be absolute there could be a 2nd coordinate type. LocalPos2 or something so if you're doing your calculations in relative the renderer/rasterizer will know this.

[museun]

The changes to make all this happen are trivial, its more about 'what should do it' than the 'how' and 'when' of it. So the changes are just minor 1 line changes.

And the rect you get in layout isn't really the same rect you'd get in draw -- layout calculates a new rect if you change size. Its there so you know what your previous size was. (Always zero/empty on first frame obv because the layout hasn't ever ran).

Render::fill etc will still fill the entire rect and it doesn't need an offset -- its more about set() / patch()

[museun]

I guess layout would need a change too, set_position offsets from your origin and isn't absolute. I think I mentioned this so it should probably be called offset and continue to be relative because you don't know where your origin will be at that point in time.