World: r3wp
[View] discuss view related issues
older newer | first last |
Terry 17-Apr-2006 [4746] | or this .. http://www.bigfatinstitute.org/index_flash.html |
Anton 17-Apr-2006 [4747] | I don't think so.. |
Terry 17-Apr-2006 [4748] | That's a fair enough rebuttal.. let's see the links to back it up. |
Pekr 17-Apr-2006 [4749x6] | Terry - very nice - what is that - flash? |
my natek on the situation - View is about to be rewritten. And it is here to stay for good imo. Well, we may not be in Flash league as for speedy and smooth presentations, but I still can't somehow find so integrated toolkit as View is. If I need small encapped app, there is not option, but View ... | |
I asked my friend about Ruby, Python - as my idea was, that corporations should throw out tools like Delphi, VB .... .NET and JAVA are goliath ... but he told me, that Python has to bind to other gui toolkits and that it is not so integrated .... he then mentioned AJAX, killing all needs for anything like View ... but - just go and find some statistics ... look at W3C and look for the state of support for all that MLs in recent browsers - you will find situation quite messy ... | |
where is SVG support? What browser it starts from? When most of old browsers will be replaced/reinstalled? I think that there is still one or even more - let's say two years to see those technologies settle a bit ... | |
Give me one thing - decent keyboard support, add tree-view, better grid to Rebgui, redesign widgets to visually support in-focus state, and you are done! Then go and look at your "app" source - very nice dialect - you will NOT find anything like that anywhere. Very nice and readable code. The problem is, VID stopped 80% on its way to success - the rest, those missing 20% ruined it. | |
now there is new attempt - DOM3 specs, to provide e.g. even hooks for your web apps .... when it will be actually developed and supported by most browsers? Dunno .... View still has some chance, especially in the browser - plug-in ..... | |
Anton 17-Apr-2006 [4755x2] | Does anyone here know about matrix math and can advise me on how to derive the same transform as is made by the draw dialect's IMAGE command with four arbitrary corner points ? |
I'm looking in the AGG source. | |
Henrik 17-Apr-2006 [4757] | One thing I love using View for is to make very quick custom GUIs for customers who need to carry out special tasks, but have no idea how to do it via the command line. It takes minutes to build something up (say a simple backup/restore system) and show them which buttons to press. It can almost be done right in front of them. I'd hate having to resort to downloading a 50-100 MB Flash development tool or build and compile Visual Basic apps, which, ooops, don't really work on their Linux box, and I just need a GUI with two buttons and a text field. Also how much system access does Flash give you? Can you create/move/delete files? It's so much nicer to say "Sure, let me do this and it can be done in an hour" rather than "I'll have a look at it at home and we'll see what I can deliver some time next week." For those things, it doesn't matter that View doesn't use Aero, Quartz Extreme or super fast hardware acceleration to display a few simple buttons. It just does the job you need to do. |
Geomol 17-Apr-2006 [4758x4] | Anton, I know about matrix math and have a book here with the standard 4x4 matrix operations for transformation like rotation, scale, etc. in 3D, if you need those. But are you sure, AGG use matrix math to do the 4-corner IMAGE trick? I would guess, it's some (2D) texture algorithm. |
Anton, one approach is to make a scanline routine. Sort the 4 corners according to y-coord. Start with the point with the lowest y-coord and look the colour up in the image (the point in that corner). For the next line (down on the monitor), you find the fraction, you've moved along the line to the point at the right side from where you started, and the same for the line to the point on the left side. Then you can find each colour for the pixels between the 2 points. You can keep doing this, until you reach one of the 2 next corners in the original corner points. Then you go along a new line to the last corner point. The same for the other end of the scanline. A problem is then to make the result look smooth. Bi-linear or tri-linear filtering can help here. I hope, I make some sense. It's a lot easier to draw than explain. | |
Maybe a little drawing can help me: 00010000 00222000 03333300 44444440 05555555 00666660 00077700 00008000 0 = background 1-8 = the 8 scanlines, this little figure is made of. The 8 scanlines are drawn starting with 1 and ending with 8. The colours in each pixel in each scanline is picked from the original image. | |
Each scanline has to be mapped onto the original image to find the colours. If such a mapping is made with straight lines, I predict the result to look ok with nice rectangle-like figures. But if one corner is far away from the rest, or moved in between the others, the result might be awful. A better way could be to map the scanlines as Bezier-curves on the original image. Could be interesting to know, how AGG does it, now that AGG's result is so good. | |
Terry 17-Apr-2006 [4762] | Also how much system access does Flash give you? Can you create/move/delete files? RASH gives any flash movie total control over the desktop via Rebol. RASH was 'absorbed' by ~Framewerks~, and now we can 'push' to the browser via RASH I've found over the years, that the best solutions are hybrids... part browser, part javascript (ajax), part rebol (uniserve), and flash (UI and pushing to the browser via flash's tcp and DOM handling) |
Anton 18-Apr-2006 [4763x5] | Geomol, I've just spent some time translating AGG code to rebol, soon I shall test it. |
Thanks for your idea, by the way, but I need to have the exact same transformation used by DRAW IMAGE with four points. I just need to transform a single point at a time. | |
So it has to be the funky perspective transform. I found include/agg_trans_perspective.h | |
But maybe if you have some C++ knowledge you can help me with this iterator class, found within class trans_perspective: class iterator_x { double den; double den_step; double nom_x; double nom_x_step; double nom_y; double nom_y_step; public: double x; double y; iterator_x() {} iterator_x(double tx, double ty, double step, const double m[8][1]) : den(m[6][0] * tx + m[7][0] * ty + 1.0), den_step(m[6][0] * step), nom_x(m[0][0] + m[1][0] * tx + m[2][0] * ty), nom_x_step(m[1][0] * step), nom_y(m[3][0] + m[4][0] * tx + m[5][0] * ty), nom_y_step(m[4][0] * step), x(nom_x / den), y(nom_y / den) { } void operator ++ () { den += den_step; nom_x += nom_x_step; nom_y += nom_y_step; double d = 1.0 / den; x = nom_x * d; y = nom_y * d; } }; //-------------------------------------------------------------------- iterator_x begin(double x, double y, double step) const { return iterator_x(x, y, step, m_mtx); } | |
Can you describe what the iterator does so I may translate the concept to rebol ? | |
Geomol 18-Apr-2006 [4768x6] | Oh, it's been a while, since I did C++, but it's something like: 6 private (internal) variables: den, den_step ... nom_y_step 2 public: x and y Constructor iterator_x without arguments does nothing. Constructor iterator_x with 3 arguments (and a constant!? The constant is an 8D vector) does (REBOL code): den: (m[6] * tx) + (m[7] * ty) + 1.0 ... y: nom_y / den Then an operator ++, so you can write: iterator_x_object++; And the operator runs the code in the function. End of class definition at the }; Then some sort of begin situation!? I think, if you make an object of class iterator_x, you give 3 arguments: x, y and step. Then m_mtx is added from somewhere. m_mtx must be defined somewhere else, I guess. |
So in all, an instance of the class iterator_x is made giving 3 arguments, and the constant m_mtx is added from somewhere. The iterator is used by using the operator ++, and the 2 variables x and y can be seen from the outside world. | |
(The instance is not made here, but can be made. This is just definition code.) | |
My REBOL code is wrong. :-) It should be: den: (m/6 * tx) + (m/7 * ty) + 1.0 | |
It's a bit weird, that m_mtx is 2 dimensional [8][1]. It's like in REBOL: m_mtx: [[1.0] [2.0]Ê[3.0].... [8.0]] where you could just do: m_mtx: [1.0 2.0 3.0 ... 8.0] | |
If you choose the first way, you have to write: den: (m/6/1 * tx) + (m/7/1 * ty) + 1.0 | |
Anton 18-Apr-2006 [4774] | I think it helps in operations with other matrices, eg: [8][8] |
Geomol 18-Apr-2006 [4775] | Probably. |
Anton 18-Apr-2006 [4776] | (don't forget to add 1 -->> m[6][0] --> m/7/1 |
Geomol 18-Apr-2006 [4777] | oh yes, you're right. Did it help with your c++ -> REBOL conversoin? |
Anton 18-Apr-2006 [4778x2] | but thanks for your overview. What's confusing to me was the constructor variable initialisation after the : (colon). I remember that notation now, and I think it looks so stupid, like they're function calls. |
I haven't converted this yet, but about to.. | |
Geomol 18-Apr-2006 [4780] | Yes, confusing. It's like they want everything to be classes, even basic datatypes like double. So you can initialize a double with something looking like a function call. Pure object-orientation is not good. :-) |
Anton 18-Apr-2006 [4781x3] | :) Here is how I will translate it: iterator-x: context [ den: none den-step: none nom-x: none nom-x-step: none nom-y: none nom-y-step: none x: none y: none init: func [tx ty step m][ den: ] ++: func [][ den: den + den-step ] ] |
Full translation like this (checking for bugs): iterator-x: context [ den: none den-step: none nom-x: none nom-x-step: none nom-y: none nom-y-step: none x: none y: none init: func [tx ty step m][ den: m/7/1 * tx + (m/8/1 * ty) + 1.0 den-step: m/7/1 * step nom-x: m/1/1 + (m/2/1 * tx) + (m/3/1 * ty) nom-step: m/2/1 * step nom-y: m/4/1 + (m/5/1 * tx) + (m/6/1 * ty) nom-y-step: m/5/1 * step x: nom-x / den y: nom-y / den ] ++: func [][ den: den + den-step nom-x: nom-x + nom-x-step nom-y: nom-y + nom-y-step d: 1.0 / den x: nom-x * d y: nom-y * d ] ] iterator-x-begin: func [x y step][ make iterator-x [init x y step m-mtx] ] | |
Now to figure out how to use these functions... | |
Geomol 18-Apr-2006 [4784] | It looks good to me. |
Anton 18-Apr-2006 [4785x3] | Holy crap I think it's working ! |
First test... do %agg-simul-eq.r do %agg-trans-perspective.r ; test trp: make trans-perspective [ init reduce [10 10 200 100 [10 10 200 10 200 300 10 300]] ; [x1 y1 x2 y1 x2 y2 x1 y2] probe transform 50 50 ] ==> [50.0 138.888888888889] | |
Excellent... :) Transforming a grid of points works. >:D | |
Geomol 18-Apr-2006 [4788] | Grats! :-) |
Henrik 18-Apr-2006 [4789] | in plain English, what's the breakthrough here? |
Geomol 18-Apr-2006 [4790x2] | My guess is, that Anton made a function in REBOL like IMAGE used in the DRAW dialect. It takes 4 points and do some calculations producing a modified image. Like what I do in Canvas, when you use perspective. I'm using DRAW for that, Anton is converting the routine from AGG C++-source. |
Maybe something like this: view layout [box 400x400 effect [draw [image logo.gif 20x20 380x50 300x380 40x100]]] | |
Henrik 18-Apr-2006 [4792] | because we can ? |
Anton 18-Apr-2006 [4793x3] | Not quite, although I think I could. What I have done is made a function which can transform a point from one space into another. Eg, for Geomol's example above, it maps from the image (logo.gif) space into the final rendered space shown on screen. So I could ask for any point in the image and find out where it is rendered to at the end. |
It's good because it matches exactly the algorithm AGG uses to draw the image (I am pretty sure anyway .:) | |
Yep, locked on solid :) | |
older newer | first last |