World: r3wp

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.

yep.

And how often would user code written in REBOL need to add origin 
checks? Style writers?

for GUIs, actually never.  unless they are building a funky style 
which manages this property specifically.

if you decide to reverse rendering direction, manually, its your 
decision.  you children should render upside down.

that is what you asking view to do.

I'm not sure if it helps, but in Flash you can set alignement as 
you need: http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary674.html
In REBOL we have TL and Maxim asks for BL.

The difference is, that in Flash you can set it only once.. but Maxim 
want's per gob alignement.

Its not alignments, its coordinate system.

With alignments the movie picture is glue to a border or centered 
in both direction.
With coordinate the picture itself would be mirrored in H or V !

Long discussion here ;) Ok, currently we are using origin(0x0) of 
coordinates from top-left corner. If I understand Maxim's request 
he wants to be able to easily change the orgin so it starts from 
bottom-left corner right?

Yes

for somethings it is easier to use top left and others bottom left 
as 0x0

Accepting that few other systems allow you to change the coordinate 
system on the fly

If this is the issue there are two solutions.

1. even now you can set the transformation matrix for example using 
MATRIX command(or other matrix related commands)  to change that

2. internally in the AGG code there is a way how to change the order 
in which the scanlines of the framebuffer are rendered in the Y-axis. 
In other words you can flip the Y axis.

the 1. is very flexible way how to setup the coordinate system ie. 
it allows you not only top-left or bottom-let but any other way you 
need.
using the 2. you can only control the Y axis nothing more

We we look at this from the performance POV:

-IIRC the transformation matrix is *always* used in the graphics 
pipeline so it doesn't matter if the matrix is set to 'top-letf' 
or 'bottom-left' or whatever else. There is no performance difference.

The only difference is that if you want to change the 'origin' you 
need to put one mroe command into the DRAW dialect block. I think 
you will agree that one more matrix command in the block can be assumed 
as almost no performance penalty.

so easy :)

same is also for the 2. the flipping of Y-axis doesn't affect the 
performance in any way no matter what mode are you using.

Also I should say that the 'flip-y' functionality is meant to be 
for the whole framebuffer = window. Se even if we expose such setting 
you won't be able to apply it per-gob, only per-window.

One more thing is that the flip-y mode is working as mirror so any 
text/images will be flipped upside down which is not usable. IMO 
any changes in that regard would slow down the scanlien rendering 
operations.

Well, even if we use the tranformation matrix the text and images 
will be upside down because that is the 'behaviour' of  Cartesian 
coordinates system.

So IMO in both case there needs to be done some additional changes 
so images/fill-patterns, vectorial text etc. will be rendered correctly. 
And I feel such changes fit more to some 'layout code functionality' 
than being part of low level rendering.

In other words it is much easier to write simple coordinate conversion 
function in REBOL for such needs.

The reason is simple: if we add that at low-level we'll slow-down 
the whole code even if you use the default coordinate system.

Just a quick thoughs so I'm open to any better ideas.

As for native code, instead of coordinate system, I would maybe more 
like to see some experiments as compound rasterizer, or other low-level 
optimisations (when time permits)

It would be good to see if there is any significant hit

Cyphre, I agree; it's already so easy to flip the y-axis in REBOL.

Anton - are you planning to create some styles for R3 GUI? IIRC in 
the past you created grid, etc., so maybe you might bring-in great 
additions ....

Graham, I still think this is really low priority thing. IMO this 
feature will be used in 1% in real usage so it is always easier to 
use the transformation or just write your own custom coordinate convesion 
function

Pekr: Ah... eventually... I have not recovered enough stamina to 
strike into this area yet.

still nothing for us to try yet?

needs more testing to see if everyone can compile the host kit.