World: r3wp

I'd say it uses bottom, cause they decided it was simpler to use 
math directly than continually adjust the trig functions for it.

Descartes

Who wasn't doing UIs. There are downsides to either approach.

The cartesian coordinate system underlies all UIs

Yes, but it wasn't designed for UIs. Another legacy system.

legacy means obsolete which it is not

both coordinate systems are optimal for their own use.

Imagine a GUI based on polar coodinates

Legacy means legacy, not obsolete.

we just need to be able to switch to and from those based on the 
current task, IMHO.

it's just a transformation ... so where would that transformation 
hurt the least

Sounds good to me. But potentially confusing - that will need to 
be managed.

by "need" I mean, it would be simpler if engine can adapt to the 
task

I'm suggesting that making the user make the transform is incorrect

no its NOT just a transformation.

the View engine should handle this transformation

so that's transparent

like silicon dioxide

It won't be transparent either way. Either you need to specify the 
direction of the coordinate system (declarative overhead) or specify 
the transform (procedural overhead). And there will be computing 
overhead either way.

I wonder if this will help in rendering letters that use an upper 
baseline

I'd imagine you just vector the computation engine so that there 
is no overhead

The question model is which is more efficient to use, both at development 
time and runtime. Letters will be tough either way (likely more for 
bottom-up), but graphics will be simpler bottom-up until display 
time.

The question model is which -> The question is which model

if we have a simple rasterization switch, per gob, then it will not 
cause any speed difference.

why exactly are we using top down?

Because AGG uses it ??

cause that is how layout is performed.

cause it rasterizes in that direction.  is my guess.   its calculations 
actually aren't different either way.

maybe we can have both

Top down is faster to render on a screen, and faster to make UI layouts 
for (extept for fixed-size windows).

top down for layout and bottom up for draw

that we can confuse so many more people

Top down for layout and text gobs, bottom up for draw? That confusion 
is the declarative overhead I mentioned earlier.

it WON'T work... you guys are missing a point.  the coordinates have 
different origins.

but each gob has its origin specified, so for a single gob, we could 
simply ask the RASTERIZER to go bottom-up.

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.