Change UI coordinate system to have origin at top left corner

[TimJentzsch]

What problem does this solve or what need does it fill?

Currently, Bevy uses a web-oriented way to do layout, with Flexbox as the main layout algorithm.
However, the origin for UI coordinates is at the bottom left instead of top left, which can be confusing.

A concrete problem this causes are the Column and ColumnReverse FlexDirection values.
According to the Flexbox spec, Column should go top to bottom and ColumnReverse bottom to top, but the opposite is true in Bevy.

What solution would you like?

Change the origin to be at the top left, with +x going right and +y going down.
Of course this would break basically all existing layouts, so it has to be done with care and rather sooner than later.

What alternative(s) have you considered?

We can also keep it as-is, but this will probably lead to confusion and issues in the future. As seen below, pretty much all other major game engines seem to have the UI origin at the top left.

Additional context

• Discord Discussion
• How do other projects do it?
  • The web: Top left
  • Unreal: Top left
  • Unity: Top left
  • Godot: Top left
  • Druid: Top left
  • Egui: Top left
  • Winit: top left

[ickk]

Note we also already have places in bevy where the coordinate system is +y down, such as Image and shaders

[alice-i-cecile]

When converting between world and UI coordinates you're always using the world_to_screen and screen_to_world helpers anyways. I don't think internal consistency is nearly as important as external consistency here.

The other key point is that this change is going to be extremely breaking in painful ways. If we want to make it, it should be ASAP, before bevy_ui develops a full ecosystem and serious users.

[tim-blackbird]

Viewport position and size also have the origin in the top-left.

bevy/crates/bevy_render/src/camera/camera.rs

Lines 38 to 44 in 07d5769

	pub struct Viewport {
	/// The physical position to render this viewport to within the [`RenderTarget`] of this [`Camera`].
	/// (0,0) corresponds to the top-left corner
	pub physical_position: UVec2,
	/// The physical size of the viewport rectangle to render to within the [`RenderTarget`] of this [`Camera`].
	/// The origin of the rectangle is in the top-left corner.
	pub physical_size: UVec2,

[Weibye]

Pretty sure winit can be added to the list with "top left" but I haven't been able to find concrete mention of it. Closest I can find is that most positions are reported as "position of the top left corner" https://docs.rs/winit/0.22.0/winit/window/struct.Window.html#method.inner_position

[Metadorius]

Don't understand why did it have to be like this in the first place. I can understand the engines having different coordinate system, but that's another deal, I haven't seen such coords being used anywhere.

[alice-i-cecile]

The original motivation, for posterity, was to have internal consistency between Bevy's 2D, 3D and UI coordinate systems, which should be consistent with standard xy graphs.

Unfortunately a) Bevy actually has many more coordinate systems, as mentioned here, which are not consistent and b) this is extremely unusual and violates users expectations :)

[Weibye]

Following a different convention than all the tech we build on top of, take inspiration from, and gain learnings from, adds friction. For this reason and the reasons posted in the description I'm strongly in favour of changing it to top-left, y-down.

If the decision is made to keep the existing convention, I would argue it only make sense if we also double down on building a novel UI solution from scratch that puts the GlobalTransform, Transform, and Visibility front and center of that experience so that it mirrors the user's experience with the rest of the engine. If the argument is "consistency", then we should actually make sure we are providing that consistency.

[cart]

I'm also on board for this change, for the record. I agree that the inconsistency with the wider UI ecosystem here has been confusing for users and the "UI coordinate system consistency with Bevy's 2d and 3d coordinate system" has yielded no tangible wins from what I have seen.