World: r3wp

Gobs are rectangular. A gob type that has an external origin point 
doesn't have to use that corner for its internal coordinates.

this will not cause any procedural overhead, and will simply reverse 
the coordinates.

from within a gob, the origin becomes the lower left corner.

Yes, that is what I meant by bottom up.

But we don't want bottom up in some cases (everything but Draw).

I know.   which is why only the rasterizer needs to know where to 
start.

but that depends on the specifics of the engine.  afaik, AGG, in 
the way it is being used by view renders each element on the canvas, 
one by one.

The coordinate system used for most OSes screen coordinates is top 
down.

brian.   it is inconsequential... its numbers .  rendering things 
starting from the bottom won't change the coordinates. it will simply 
invert them without requiring you to adapt any number.

Max .. suggest it to Carl

Maxim, do you not get that I am agreeing with you? I am just disagreeing 
that it should be bottom-up all the time :)

I never said it should be all the time... it can easily be a switch 
on each gob.

Some gob types (only Draw, maybe images, afaict) would benefit from 
bottom up.

as long as the gob knows its size it knows how to move its origin 
wrt its parent gob and render upside down.

Having a switch on new gobs will add to complexity. Having it fixed 
per gob type lowers complexity (outside of docs and tutorials).

it should be a switch, since you want your coordinates to align. 
 if you have to add graphics to text, for example, they should use 
the same coordinate system.

Complexity is the enemy for the R3 GUI.

If you have to add graphics to text, you are using Draw.

it won't add to the complexity.  that's the point of it being a switch.

if you are building your own draw gobs, you have an 'option'  for 
it to render upside down.  that's it.

You can't add graphics to a text gob. Or any of the other specialized 
gobs, just to the draw gob.

yes I know, I am speaking high-level here, sorry.  if you have to 
match values of different gob types which render in different directions, 
it will be mayhem.

which is why it must be a switch.   within everything using the same 
direction by default.

They don't render in different directions. All of them render from 
the top down. What you are talking about is internal coordinates. 
How the gob is located externally has nothing to do with how it is 
coordinated internally.

Gobs can contain other gobs.

yes I know all of this.    i am trying to add functionality to the 
rendering engine... its totally invisible to actual gob high-level 
constructs.

and allowing a switch to the gob, so it can tell *only* the rasterizing 
engine to render bottom up, using all of the internal coordinate 
values AS-IS.

this effectively adds very little overhead, and solves the issue 
for all cases.

So all you are talking about is Draw. It wouldn't have anything to 
do with switches to a gob, since it would be fully contained within 
one gob.

no, I want all gob children to obey the direction.

Except for gob children that aren't Draw gobs.

why prevent them from accessing the feature?  if the rasterizer can 
work on either directions, I think all gobs should have the capability 
to control this.  they would simply inherit the "current" direction 
or not based on type, but they should be allowed to render upside 
too, if specifically required.

you are assuming view is used to draw GUIs, but its used for other 
things too.

R3 GUI would be top-down by default for everything.

There is no problem with the external coordinate system that placed 
a gob being completely different from its internal coordinate system. 
It just adds complexity. But having the coordinate system be inherited 
adds so much more complexity (modal behavior) that it is a bad idea. 
It is better to have each gob have a predictable coordinate system, 
not a different one based on its container.

I am having trouble explaining this to you without pictures.

it depends on gob type.  font should not inherit by default, draw 
should.  but I might want to render text upside to create a reflection, 
without incurring the hit of applying a transform to the coordinates...

All such things should be done with draw gobs.

but I also might draw to render top-down.

Complexity is the enemy here. We don't want to add too many options, 
because processing them has overhead in mental, development time 
and runtime. Pick a coordinate system.

direction would be a tri-state 'up 'down none.


none means inherit.   all gob types would have their defaults set 
to one of the three states.

the fact that its implemented as above, means its consistent and 
simple.

if each type does something different then everything becomes complex, 
except for one if condition in the run-time.

Sorry, you lost me at "inherit". I'll have to let Cyphre chime in 
from this point.

again, I'd have to look at the AGG rasterizing pipeline to see how 
it functions, but the only procedural overhead is in how it inherits 
its origin at each gob.   


it might even be impossible from the get-go, based on how the actual 
rasterization is performed.  


in Flash this would be impossible.  but IIRC past discussions with 
Cyphre, we use a different rasterizing process, which would allow 
the whole idea.

You keep looking at procedural overhead and ignoring conceptual and 
declarative overhead. Keep those in mind, please.

no I am not.  


the implementation example allows a 100% invisible to current use, 
 without any in-REBOL code added.


applying it is a simple assignment of a value to a (new) gob! property.

conceptually is solves a problem in just about GUI engines out there. 
 and its dead simple to use and understand.

And with that added option, how simple is it to check the gobs to 
make sure the option isn't specified? Multiply that answer by the 
number of times that check would need to be added to code. That is 
why you lost me at "inherit". But if you can convince Carl and Cyphre, 
go for it.

the way I see it the direction would be managed at the same place 
and time any origin check is performed.

at the same place and time any origin check is performed
 - That is the added complexity, the origin checks.