World: r3wp
[!REBOL3 GUI]
older newer | first last |
BrianH 12-Aug-2010 [2537] | Is there a problem with having Draw gobs be bottom-left, but text gobs top-left? |
Maxim 12-Aug-2010 [2538x3] | 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. | |
Graham 12-Aug-2010 [2541] | TV guys like Carl start at the top |
Maxim 12-Aug-2010 [2542x2] | is = it |
yes, hardware scanlines are managed top first. | |
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 [2586] | I know. which is why only the rasterizer needs to know where to start. |
older newer | first last |