World: r3wp

Why View should admit defeat.. 
http://demo.arcww.ca/sites/lblaunch/

or this .. http://www.bigfatinstitute.org/index_flash.html

I don't think so..

That's a fair enough rebuttal.. let's see the links to back it up.

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 .....

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.

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.

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.

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)

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 ?

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

I think it helps in operations with other matrices, eg: [8][8]

Probably.

(don't forget to add 1  -->> m[6][0] --> m/7/1

oh yes, you're right. Did it help with your c++ -> REBOL conversoin?

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..

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. :-)

:) 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...

It looks good to me.

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

Grats! :-)

in plain English, what's the breakthrough here?

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]]]

because we can
?

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 .:)