This week I have been working with product from GE called a Quick Panel, which is basically a stand alone touch screen computer appliance with a mini SCADA system built in. I have been using it to build some operator displays for a crane system and needed to implement some position and size animation of a coloured box to indicate the relative position of the crane to a fixed reference. No problem, just drop a box into the screen designer, edit the size and position animation properties to be based on external numbers (coming from the crane itself) and I'm done. I go to test it and the box moves up instead of down. It turns out that even though the co-ordinate system of the screen has the top left as (0,0) and the documentation says that my increasing the number controlling the animation will add pixels to the vertical position property, they actually meant subtract. Of course the horizontal positioning did work as expected. Or to put it another way, the basic screen layout software that drops objects on the screen references the top left as the origin, the animation properties of the objects you put on those same screens reference the bottom left as their origin.

It sounds easy to adjust for once you are aware of it, but it does make you wonder about what prompted that choice.

locallunatic:

...but it does make you wonder about what prompted that choice.

It's probably something innocent like the people who wrote the animation routines decided to be helpful and convert from physical coordinates to a more animation-friendly coordinate system.  Drawing libraries are full of this kind of stuff.  One of the more interesting ones is the behavior difference betwen drawing and filling.  In many systems, in order to fill the box that you drew at x=100, y=100, height=100, width = 100, you have to fill the rectangle at x=101, y=101, height=99, width=99.  It makes perfect sense if you know how pens and brushes differ, but it looks weird when you first get into it.

locallunatic:

it does make you wonder about what prompted that choice.

You're assuming that there was a choice. I have dealt with GE software (actually GE-IP) for a long time and this was only the latest thing that happened to me. Their systems have all sorts of fun gotchas in them.

You're holding it wrong.

Jaime:

locallunatic:

...but it does make you wonder about what prompted that choice.

It's probably something innocent like the people who wrote the animation routines decided to be helpful and convert from physical coordinates to a more animation-friendly coordinate system.  Drawing libraries are full of this kind of stuff.

I like to use center screen as origin with Y up, so there's a matrix transformation I usually apply when dealing with top-left origin Y is down (that seems so common yet completely backward).

 In text editors, you have a choice of paradigms when it comes to "up" and "down".  The usual resolution is that going further on in a document is "down", because you picture a fixed scroll with the doc on it and moving your viewpoint up and down along it.  A minority of editors have taken the opposite view, that your viewpoint is fixed and you move the entire document up or down behind the screen-sized window you're viewing it through.

I once had to deal with an editor where two groups each picked an interpretation without consulting one another.  If you were in the middle of a doc and repeatedly scrolled "down", you'd eventually arrive at the end of the file.  But you could also jump to that point in one step by scrolling to "top".  "Up" and "bottom" were likewise implemented as being the same direction.

locallunatic:

It sounds easy to adjust for once you are aware of it, but it does make you wonder about what prompted that choice.

 

 Are you kidding? Putting the origin at the top left of the screen is the standard for GUI software (because text flows this way). Also, putting the origin at the botton left of the crane is the standard for actuator design (because everybody draws this way since colege).

 

 

Mcoder:

 Are you kidding? Putting the origin at the top left of the screen is the standard for GUI software (because text flows this way). Also, putting the origin at the botton left of the crane is the standard for actuator design (because everybody draws this way since colege).

My point was the fact that you are saying "draw this here" but using different orgins depending which way you say it.

locallunatic:

 

My point was the fact that you are saying "draw this here" but using different orgins depending which way you say it.

 

You were wondering why they choosed those conventions. Well, they are the standard ones, for each application.

I didn't say that it made any bit of sense to use them toghether. It doesn't. But it is no mistery why they choosed them. (Probably two different teams thought of them as such non-brainers that they didn't even think they should agree on something here.)

 

Jaime:

In many systems, in order to fill the box that you drew at x=100, y=100, height=100, width = 100, you have to fill the rectangle at x=101, y=101, height=99, width=99. 

Depending on what random system you're talking about, that could be fill: x=101, y=101, height=98, width=98? 99 would cover 2 borders with your fill color!

 what if the screen hardware is actually upside down and you have found a bug?

darkmattar:

Depending on what random system you're talking about, that could be fill: x=101, y=101, height=98, width=98? 99 would cover 2 borders with your fill color!

I'm talking about Windows GDI+, and the problem isn't just unexpected behavior; there is a solid rationale behind the behavior.  The unexpectedness of GDI+ behavior comes from the fact that it is a floating point coordinate system, so a line following a rectangular path with a center-to-center width of 100 pixels and a line width of 1 pixel has only 99 pixels of space between the inside edges of the lines.  I can't think of a rational coordinate system that would behave the way you suggest.  Do you have any examples?

Jaime:

I can't think of a rational coordinate system that would behave the way you suggest.  Do you have any examples?

Partly a poor translation on my part - I meant that if the x=100 with height =100 INCLUDING the borders, then the bottom is drawn at 199 and the fill is 101->198. It's been a long time, but I swear I remember that being how it worked on some old black&white lcd screens where you only had like 80x40 or 320x240 resolutions. Then again, I'm probably just thinking of assembly logic sans libraries, drawing the rectangle manually, by doing the line at x=100 & x=199 and then filling from x=101 -> x=198. But if your library function draws the border at x=100 and x=200 with 101->199 filled, that's a rectangle with a 101pixel height, not 100. Edit:

Jaime:

center-to-center width of 100 pixels and a line width of 1 pixel has only 99 pixels of space between the inside edges of the lines. 

There's the key: Center-to-Center width. I was referring to systems with fat pixels and crappy resolution as opposed to modern PCs.