New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zorder is very unpredictable. #401

Closed
oomek opened this Issue Dec 31, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@oomek
Collaborator

oomek commented Dec 31, 2017

When you run this layout

local tiles = []
for (local i = 0; i < 10; i++)
{
	local obj = fe.add_text("txt", 100 * i, 0, 100, 100)
	obj.nomargin = true
	obj.charsize = 30
	obj.align = Align.Centre
	tiles.push(obj)
}

tiles[0].zorder = 100
tiles[9].zorder = 101

for (local i = 0; i < 10; i++)
{
	tiles[i].msg = tiles[i].zorder
}

a common sense makes you believe that the result on the screen will be
100 1 2 3 4 5 6 7 8 101

but instead you get:
8 0 1 2 3 4 5 6 7 9

AM should allow in my opinion to set zorder greater that the number of total drawable elements.
At the current state the whole zorder table behaves very unpredictable as it gets shifted every time you modify some zorder value.
When I set the zorder of an object I wish it stays the same.

@oomek

This comment has been minimized.

Show comment
Hide comment
@oomek

oomek Jan 1, 2018

Collaborator

One more thing. In case when zorder has the same values the elements should be drawn in the order they have been initialised.

Collaborator

oomek commented Jan 1, 2018

One more thing. In case when zorder has the same values the elements should be drawn in the order they have been initialised.

@liquid8d

This comment has been minimized.

Show comment
Hide comment
@liquid8d

liquid8d Jan 6, 2018

@mickelson explained this to me here:

#353

Using zorder just bumps that object up in the draw list, but I agree - we need to have better control of zorder for it to be useful.

Typical use case for zorder would be to temporarily bring an object to the front, then return it to where it was. You can't really do this without defining zorders for every single object, which becomes a pain. Ideally, we want to use zorder just like zindex for css - everything draws in order of creation - unless it has a set zorder, in which case it inserts itself in that position. Meaning everything has 0 zorder, but if multiple objects have 1 - draw them above all 0's (BUT still in the order they were created).

If the draw list is just an array, rather than make zorder its position in the array - perhaps you can make zorder an attribute of the object. When rendering the draw list, draw objects in order they were created, looping through each zorder number. Optionally, since changing zorder might break existing layouts - you could add a 'zindex' attribute and use that. (hopefully that makes sense)

liquid8d commented Jan 6, 2018

@mickelson explained this to me here:

#353

Using zorder just bumps that object up in the draw list, but I agree - we need to have better control of zorder for it to be useful.

Typical use case for zorder would be to temporarily bring an object to the front, then return it to where it was. You can't really do this without defining zorders for every single object, which becomes a pain. Ideally, we want to use zorder just like zindex for css - everything draws in order of creation - unless it has a set zorder, in which case it inserts itself in that position. Meaning everything has 0 zorder, but if multiple objects have 1 - draw them above all 0's (BUT still in the order they were created).

If the draw list is just an array, rather than make zorder its position in the array - perhaps you can make zorder an attribute of the object. When rendering the draw list, draw objects in order they were created, looping through each zorder number. Optionally, since changing zorder might break existing layouts - you could add a 'zindex' attribute and use that. (hopefully that makes sense)

@oomek

This comment has been minimized.

Show comment
Hide comment
@oomek

oomek Jan 6, 2018

Collaborator

I’m happy that you agree that zorder function needs rewriting. For this moment i’ve overome it by specifying the zorder=9999 for the objects I need in front in tick function including my custom overlay elements. It works but I hipe it does not bring any penalties in performance.

Collaborator

oomek commented Jan 6, 2018

I’m happy that you agree that zorder function needs rewriting. For this moment i’ve overome it by specifying the zorder=9999 for the objects I need in front in tick function including my custom overlay elements. It works but I hipe it does not bring any penalties in performance.

@mickelson

This comment has been minimized.

Show comment
Hide comment
@mickelson

mickelson Jan 8, 2018

Owner

Ok I'm game for changing how zorder works. The only pain is that this change will inevitably break people's existing layouts, so I want to make sure it is right the first time so that any breaks only have to be fixed once. So here is what I propose (which can be implemented fairly easily):

  • zorder can be set to any positive or negative integer value. the zorder will be an attribute that stays at whatever value is set
  • lower zorders are drawn first
  • default zorder is 0
  • objects with the same zorder will preserve their relative ordering. So when an object is first added, it will be the last object at zorder '0' that gets drawn. If its zorder is set to -1 and then back to 0, it will become the first object at zorder '0' that is drawn. If its zorder is set to 1 and then back to 0, it will become the last object at zorder '0' that is drawn...

thoughts?

Owner

mickelson commented Jan 8, 2018

Ok I'm game for changing how zorder works. The only pain is that this change will inevitably break people's existing layouts, so I want to make sure it is right the first time so that any breaks only have to be fixed once. So here is what I propose (which can be implemented fairly easily):

  • zorder can be set to any positive or negative integer value. the zorder will be an attribute that stays at whatever value is set
  • lower zorders are drawn first
  • default zorder is 0
  • objects with the same zorder will preserve their relative ordering. So when an object is first added, it will be the last object at zorder '0' that gets drawn. If its zorder is set to -1 and then back to 0, it will become the first object at zorder '0' that is drawn. If its zorder is set to 1 and then back to 0, it will become the last object at zorder '0' that is drawn...

thoughts?

@oomek

This comment has been minimized.

Show comment
Hide comment
@oomek

oomek Jan 8, 2018

Collaborator

Sounds logical and functional to me

Collaborator

oomek commented Jan 8, 2018

Sounds logical and functional to me

mickelson added a commit that referenced this issue Jan 8, 2018

Issue #401 - Implement proposed changes to zorder behaviour
- This changes the behaviour of the zorder attribute of image, text,
  and listbox objects.  *** Layouts that use the zorder attribute
  may have to be updated as a result ***

- zorder attribute can be set to any integer value.  The value stays
  at whatever it is set to (previous behaviour was that all objects
  had a unique zorder value, forced in to the range of 0 to number
  of objects-1)

- objects with a lower zorder are drawn first.  Order remains stable
  when objects are assigned the same zorder.

- Default zorder value is 0, with objects drawn in their order of
  creation

- updates to loader/hyperspin.nut to address zorder changes
@mickelson

This comment has been minimized.

Show comment
Hide comment
@mickelson

mickelson Jan 8, 2018

Owner

Pull request with proposed changes: #408

Owner

mickelson commented Jan 8, 2018

Pull request with proposed changes: #408

mickelson added a commit that referenced this issue Jul 12, 2018

Issue #401 - Implement proposed changes to zorder behaviour (#408)
- This changes the behaviour of the zorder attribute of image, text,
  and listbox objects.  *** Layouts that use the zorder attribute
  may have to be updated as a result ***

- zorder attribute can be set to any integer value.  The value stays
  at whatever it is set to (previous behaviour was that all objects
  had a unique zorder value, forced in to the range of 0 to number
  of objects-1)

- objects with a lower zorder are drawn first.  Order remains stable
  when objects are assigned the same zorder.

- Default zorder value is 0, with objects drawn in their order of
  creation

- updates to loader/hyperspin.nut to address zorder changes

@oomek oomek closed this Jul 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment