World: r3wp
[!REBOL3 GUI]
older newer | first last |
BrianH 12-Aug-2010 [2544] | Postscript goes from the bottom because it rendered to paper, not screens. |
Graham 12-Aug-2010 [2545] | display postscript |
BrianH 12-Aug-2010 [2546] | Which was derived from Postscript, and so inherited its coordinate model, for better or worse. |
Maxim 12-Aug-2010 [2547] | I'd say it uses bottom, cause they decided it was simpler to use math directly than continually adjust the trig functions for it. |
Graham 12-Aug-2010 [2548] | Descartes |
BrianH 12-Aug-2010 [2549] | Who wasn't doing UIs. There are downsides to either approach. |
Graham 12-Aug-2010 [2550] | The cartesian coordinate system underlies all UIs |
BrianH 12-Aug-2010 [2551] | Yes, but it wasn't designed for UIs. Another legacy system. |
Graham 12-Aug-2010 [2552] | legacy means obsolete which it is not |
Maxim 12-Aug-2010 [2553] | both coordinate systems are optimal for their own use. |
Graham 12-Aug-2010 [2554] | Imagine a GUI based on polar coodinates |
BrianH 12-Aug-2010 [2555] | Legacy means legacy, not obsolete. |
Maxim 12-Aug-2010 [2556] | we just need to be able to switch to and from those based on the current task, IMHO. |
Graham 12-Aug-2010 [2557] | it's just a transformation ... so where would that transformation hurt the least |
BrianH 12-Aug-2010 [2558] | Sounds good to me. But potentially confusing - that will need to be managed. |
Maxim 12-Aug-2010 [2559] | by "need" I mean, it would be simpler if engine can adapt to the task |
Graham 12-Aug-2010 [2560] | I'm suggesting that making the user make the transform is incorrect |
Maxim 12-Aug-2010 [2561] | no its NOT just a transformation. |
Graham 12-Aug-2010 [2562x3] | the View engine should handle this transformation |
so that's transparent | |
like silicon dioxide | |
BrianH 12-Aug-2010 [2565] | 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. |
Graham 12-Aug-2010 [2566x2] | 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 | |
BrianH 12-Aug-2010 [2568x2] | 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 | |
Maxim 12-Aug-2010 [2570] | if we have a simple rasterization switch, per gob, then it will not cause any speed difference. |
Graham 12-Aug-2010 [2571x2] | why exactly are we using top down? |
Because AGG uses it ?? | |
Maxim 12-Aug-2010 [2573x2] | cause that is how layout is performed. |
cause it rasterizes in that direction. is my guess. its calculations actually aren't different either way. | |
Graham 12-Aug-2010 [2575] | maybe we can have both |
BrianH 12-Aug-2010 [2576] | Top down is faster to render on a screen, and faster to make UI layouts for (extept for fixed-size windows). |
Graham 12-Aug-2010 [2577x2] | top down for layout and bottom up for draw |
that we can confuse so many more people | |
BrianH 12-Aug-2010 [2579] | Top down for layout and text gobs, bottom up for draw? That confusion is the declarative overhead I mentioned earlier. |
Maxim 12-Aug-2010 [2580x2] | 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. | |
BrianH 12-Aug-2010 [2582] | Gobs are rectangular. A gob type that has an external origin point doesn't have to use that corner for its internal coordinates. |
Maxim 12-Aug-2010 [2583] | this will not cause any procedural overhead, and will simply reverse the coordinates. from within a gob, the origin becomes the lower left corner. |
BrianH 12-Aug-2010 [2584x2] | Yes, that is what I meant by bottom up. |
But we don't want bottom up in some cases (everything but Draw). | |
Maxim 12-Aug-2010 [2586x2] | 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. | |
BrianH 12-Aug-2010 [2588] | The coordinate system used for most OSes screen coordinates is top down. |
Maxim 12-Aug-2010 [2589] | 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. |
Graham 12-Aug-2010 [2590] | Max .. suggest it to Carl |
BrianH 12-Aug-2010 [2591] | Maxim, do you not get that I am agreeing with you? I am just disagreeing that it should be bottom-up all the time :) |
Maxim 12-Aug-2010 [2592] | I never said it should be all the time... it can easily be a switch on each gob. |
BrianH 12-Aug-2010 [2593] | Some gob types (only Draw, maybe images, afaict) would benefit from bottom up. |
older newer | first last |