World: r3wp

Can't you use a draw transform?

even text rendering is more naturally understood looking up, from 
the baseline.

I think that's what Cyphre also argues .. to use a transform

transforms cause all kinds of complicated issues.  it will also slow 
down calculations since its applied within the pipeline, instead 
of directly within the engine.

whichever gives us the greatest speed should be the one we use

Is there a problem with having Draw gobs be bottom-left, but text 
gobs top-left?

it won't make a difference in speed.   its just a questing of the 
order of rasterizing, start at bottom or start at top.

yes, the coordinates will be inversed.

unless that is managed internally, which is could.

TV guys like Carl start at the top

is = it

yes, hardware scanlines are managed top first.

Postscript goes from the bottom because it rendered to paper, not 
screens.

display postscript

Which was derived from Postscript, and so inherited its coordinate 
model, for better or worse.

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.