AltME groups: search

But we need queality of output, which View does not have. AGG is 
big step forward, but for vectors ... I want transitions though and 
that is - I want pixel VM or other goodie. But imo without some kernel 
changes, we will never be smooth enough.

but why not be kings, if we could be kings ... how would you do image 
transitions, if we will not have fast means of pixel changes? Pokeing 
at image is not the way to go ... hopefully Cyphre has something 
in mind and will influence Carl a bit as he did with AGG ....

otoh I don't give up on possibility to make things better. Some of 
us were telling View was OK even before AGG, now we know AGG was 
good addition. The same may go for few small twist to View kernels, 
which would open many more possibilities ....

dumb question: is there a REBOL build with AGG available yet?

Normally, VM should be lighter when the dual rendering core will 
be removed: actually, there is the old Rebol one (for effects and 
text) and the AGG one (for Draw). Effects needs to be proted on AGG 
AFAIK

It's just REBOL, Reichart, so it uses AGG on newer releases. It just 
generates DRAW commands.

PNG can't scale, no? And I can be PNG file smaller than vectors transferred? 
The slowness of whole stuff is another thing.  Dunno if we can support 
SVG out-of-the-box. We are using AGG, while the rest of the world 
is using Cairo.

What about JIT method for AGG I posted earlier?

Then we should order Cyphre to do few AGG tests :-)

I've been investigating the bug above with this script:

do read http://anton.wildit.net.au/rebol/view/draw/agg/image-fit.r

Hmm.. that's a bit annoying. Is there really no way the bilinear 
filter can work also on the alpha channel ? That would be a feature 
request to submit to AGG then wouldn't it ?

Anton, according to the author of AGG the filter calculations would 
be much more complex and thus expensive if done in plain color space. 
Anyway, please submit a ticket to RAMBO I'll try to make the best 
to solve this issue.

I  wonder why scrollers have such terrible lag on 1.8GHz pentium. 
Although new demo si cool, I wonder if REBOL it is not able to provide 
us with real-time feeling even if AGG is on-board?

I am not sure AGG supports SVG directly? I expect it being very capable 
vector engine, so we have to build kind of SVG parser plus viewer 
ourselves? Or am I wrong?

I just hacked the graph-layout stuff found in Rebol-Framework into 
a standalone using the new AGG stuff. Very cute and fast!! Take a 
look at: http://www.robertmuench.de/download/graph-layout.r

Henrik - your zoomer is nice - I vote for it to be included in View 
Desktop test folder - nice example of AGG usage .... although REBOL 
is bitmap, or not? Once enlarged, I can see R and O letter with jaggies 
... :-)

pekr, yes, it's bitmap. I noticed someone asked about a performance 
measuring tool for AGG perspective mapping, but I didn't have much 
time, so it became a rotation zoomer.

would be nice to see some organized effort for View 1.4. using AGG, 
perhaps some desktop searching, fancier graphics, etc.

oh my, we can see very nice demos in desktop demo folders, with "designs" 
like Calculator .... those should be removed, redesigned, or they 
somehow descredit current Rebol's AGG capabilities ;-)

I'm absolutly convinced that draw/AGG capabilities open to us a true 
amazing scope of posibilities

AGG based app - nice :-) http://www.epsitec.ch/cresus/documents/base-f.php

We had such discussion before, do you remember? Many ppl arguing 
with Terry, that basically rebol draw is capable to compete with 
Flash and nowadays we are all applauding AGG inclusion :-) I just 
try to point out to things I don't like and I try to believe that 
my pressure may lead to think out some things more deeply for 1.4 
release ...

Graham - and besides that - we don't know the plan, do we? It is 
difficult to work/cooperate, as RT choosed the way when design is 
done by few ppl. It is good on one hand, as work is being finally 
done and we have got 1.3 out fast enough, but no docs follow, no 
plans follow. I e.g. asked someone from RT's extended team describe 
proper behavior of Installer, to actually test what is desired and 
what is not. But I can imagine docs are always lower priority, it 
is simply natural. But - I would really like to know, what goes for 
VID 1.4 or 1.3.x, whatever - only styles additions? What will happen 
to focus system, how will accessors be utilised, the same for doc 
subobject, what happens to VID in general?  - btn uses bitmap, but 
we've got powerfull AGG inside. Also - how will effects be merged 
with draw? We want to keep compatibility on one hand, but surely 
we don't want to have powerfull gradients withing draw, and old-ones 
within effect block ... So - don't ask me - I would expect some developers 
oriented document, short description of what and how is gonna be 
solved. Don't forget that it seems text mark-up is gonna be introduced 
- so - many changes, in hundreds of possible ways - so I will not 
propose conrete solution, if I know nothing about more general plan 
...

... what is more - more kernel changes will come - AGG, effect block 
vs draw effects, possibly compositing based upon AGG (new in AGG), 
fonts etc.

Petr: the argument about View vs. Flash was about AGG View, not the 
old View.

Gabriele - I am not sure, with Terry, it was imo old View vs Flash, 
then came-in devcon and first introduction of AGG, which was happily 
applauded, but it does not really matter ...

Petr: i remeber that discussion very well, i was the one to say that 
View was going to be better soon, and i said that because i was testing 
AGG View already.

And what is more, - there are other planned changes to View kernel 
- fonts in AGG  (under considertion IIRC), text mark-up, 'min-face, 
which will maybe in itself influence even current VID and the way 
we use it, if such concepts are implemented ...

Levelarc is nice but unfortunately shows some small but noticeable 
inaccuracies in agg (implementation ?). Not a showstopper and hopefully 
they will be fixed in good time.

http://matplotlib.sourceforge.net/fonts.html, they say "The GD, Agg, 
and Paint backends all support freetype fonts, which provide high 
quality, anti-aliased font rendering to PNG and JPEG output without 
X support.". Not directly usable for us, its a python plotting lib. 
But maybe something can be learned from the source, or asking them?

AGG is sub-pixel correct ;)

AGG used in the draw dialect is very good at anti-aliasing. But then 
some (maybe) unexpected results occur, when anti-alias is turned 
off:

Geomol: regarding AGG in ALIASED mode: I'm working on improvements 
in this mode so the graphic shoudl be 'pixel precise'.

Better ask in AGG ?

Graham - is it? :-) I thought they have their "co-operators" from 
community now, no? Gabriele taking care of some bits of networking/LNS, 
Cyphre AGG stuff, Gregg something else and IIRC it was Romano who 
did some changes to VID focusing, no? So that is why I asked "anyone" 
instead of RT ... :-)

Thanks Sunanda. That AGG Sudoku by James is very nice. It needs some 
bells and whistles like undo as well as the Functions mentioned in 
the script - like help, solve, hint but very nice effort.

where's the agg docs ?

cool :)  I just wanted to make something in agg :)

Do you know if AGG supports not rectangular view ports ?

maybe as we found AGG, some small and cute 3D one plus compositing 
one could be found and integrated too :-)

because text is drawn with AGG

agg-text: it works i wine.

The list doesn't work in the browser as the list needs AGG.  It works 
in View, but doesn't do anything at present except display online 
status.  It scales for me fine up to 1024x768.

the AGG part... right. the sort button uses AGG to display the sorting 
arrow. I could make that into an image and do some tests on an older 
View and see if it can run there...

I think I've gotten rid of the AGG dependency and that will be part 
of 0.0.15, but there are many other dependencies, so I don't know 
whether it'll work with the plugin.

0.0.15 uploaded

Changes:
      New: Updated documentation with images
      New: DATA can now also be a single block of values
      Fix: IN-COLS is no longer mandatory
      Fix: MAIN-COL is no longer mandatory
      New: Default WIDTHS now a fraction value.
      New: Fractional widths of the list width as decimals
      Fix: List size calculation optimizations

      Fix: Scroller width is now always equal to the corner reset button 
      width
      New: SCR-WIDTH lets you set the scroller width
      Fix: AGG is no longer a requirement
      New: CLEAR to quickly clear the list

The files have moved again:
    http://www.hmkdesign.dk/rebol/list-view/list-view.r

    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view/list-view.html

Well, I got the new plugin working with AGG.

This way I at least can manually upgrade my own client plugin to 
AGG.

AGG, and no ASYNC?

with AGG, we are able to create really nice qraphs ... but dunno 
if worth-it when looking at packages as RRDTool :-)

Volker, of course you're right, I always forget that. So here's a 
proof-of-concept of an AGG field style:

someone wante graphing, dunno what group was it posted in - one interesting 
project using AGG and Python - Matplotlib - done using AGG - http://matplotlib.sourceforge.net/screenshots.html

I am not sure how universal the library is for graphing ... maybe 
if we want to do graphing, we should look for the best of kind library, 
then to port ... I am not sure if there is any advantage to matplotlib 
- it calls agg library, which we have inside of rebol already, so 
:-)

I think, we have a problem with the way, AGG is implemented. E.g. 
arguments to LINE are pairs (like 100x100). To be able to make a 
smooth curve using LINE, the arguments have to be decimals. Try the 
following code to see:

I don't think you can squeeze everything into the DRAW block, but 
you can of course do it inside the EFFECT block. I do remember seeing 
in the AGG test program in the Viewtop something that let you use 
transparency on top of an image, but I'm not sure taht's what you 
want

I'm looking in the AGG source.

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.

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.

Geomol, I've just spent some time translating AGG code to rebol, 
soon I shall test it.

So it has to be the funky perspective transform. I found  include/agg_trans_perspective.h

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]

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.

It's good because it matches exactly the algorithm AGG uses to draw 
the image (I am pretty sure anyway .:)

... another option I remember was to switch to compound rasterizer 
of AGG. And - REBOL timers are still substandard of what can be achieved 
imo ... But, as Carl said - those parts are going to be host part, 
hence open-source. We just need Carl to release sources. Hopefully 
it happens till I retire :-) (eventual replies to REBOL3 group, just 
wanted my comments to be at one channel)

In the past, there were Gabriele and Cyphre. Gab did initial VID3, 
http protocol and maybe other things. Cyphre did View kernel things 
- e.g. whole compositing engine was replaced by the better one - 
AGG based ...

does Orca support AGG dialect?

We don't have an AGG port yet for Syllable, either, but I hear it 
just compiles. Integration is another story, though

I found following - http://www.compkarori.com/vanilla/display/AGG
... but strange thing is, that fonts are wrong even in console, not 
in view ...

'lo. Pinged Cyphre on ICQ. He told me:


1) fonts, which are rendered in face/text
2) fonts, which are rendered in DRAW (AGG)


re 1) IIRC, REBOL uses some X-Windows function, an old method, which 
should work on all distros

re 2) REBOL uses FreeType2 library to get vector data, which are 
then rendered via AGG

Ashley, Ubuntu works fine .. you just have to specify the full path 
to any fonts you use if using AGG fonts.

Are you talking about AGG or standard View text? For the latter, 
anything that X can use REBOL can use, in principle at least. For 
the former, I think any TTF file will work (notice that you can install 
the MS Core Fonts package).

this way ... http://www.compkarori.com/vanilla/display/AGG

I wasn't aware that agg fonts don't display in OSX .. but since it's 
also BSD based probably.

I tried to change the agg script to point to a ttf font file under 
OS X. It doesn't display.

Cyphre is not sure, if there is support for fonts in AGG under OS-X, 
he did it together with Carl, but long time ago ...

Not AGG

R2 uses different methods to do regular graphics and Draw. Draw is 
done only with AGG, the rest of View is not. The font code is different.

For R3, all graphics are done with AGG. Don't know yet about the 
font support on Linux.

maybe I'm wrong and I didn't try anything fancy, but don't you think 
we might have problems in rendering the same stuff from the page 
you gave the link - I guess these things are accelerated by the graphics 
card and AGG is not, no ?

rebol []
stylize/master [
	agg-progress: box white "0%" with [
		pstart: pend: pfunc: none
		progress: 50
		oldprogress: 0
		update: does [
			if (self/progress <> self/oldprogress) [
				self/oldprogress: self/progress

    self/effect: compose/deep [draw [pen none fill-pen linear 0x0 0 (self/size/x) 
    25 1 1 red yellow cyan blue box 0x0 (as-pair self/size/x * (self/progress 
    / 100) self/size/y)]]
				self/text: join to-integer self/progress "%"
				show self
			]
		]
		append self/init [self/update]
	]
	rate 25
	feel [
		engage: func [face action event][
			if action = 'time [
				if (face/progress <= 100) and (face/progress >= 0) [

     face/progress: to-decimal ((face/pfunc - face/pstart) * 100 / to-decimal 
     (face/pend - face/pstart))
					face/update
				]
			]
		]
	]
]
view/title center-face layout/tight [

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pstart: now/time/precise pend: pstart + 30 pfunc: does [return now/time/precise]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pend: now/time/precise pstart: pend + 30 pfunc: does [return now/time/precise]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pstart: 0 pend: 100 pfunc: does [random/seed now/precise return 
 random 100]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [rate: none progress: 50]
] "AGG progress bar"

stylize/master [
	agg-progress-pie: box white "0%" with [
		pstart: pend: pfunc: none
		progress: 50
		oldprogress: 0
		update: does [
			if (self/progress <> self/oldprogress) [
				self/oldprogress: self/progress

    self/effect: compose/deep [draw [pen none fill-pen conic (self/size 
    / 2) 0 (self/size/x / 2) 90 0.5 0.5 red yellow cyan blue arc (self/size 
    / 2) (self/size / 2) 0 (self/progress * 360 / 100) closed]]
				self/text: join to-integer self/progress "%"
				show self
			]
		]
		append self/init [self/update]
	]
	rate 25
	feel [
		engage: func [face action event][
			if action = 'time [
				if (face/progress <= 100) and (face/progress >= 0) [

     face/progress: to-decimal ((face/pfunc - face/pstart) * 100 / to-decimal 
     (face/pend - face/pstart))
					face/update
				]
			]
		]
	]
]
view/title center-face layout/tight [

 agg-progress-pie 100x100 font [size: 11 color: none shadow: none] 
 with [pstart: now/time/precise pend: pstart + 30 pfunc: does [return 
 now/time/precise]]

 agg-progress-pie 100x100 font [size: 11 color: none shadow: none] 
 with [pend: now/time/precise pstart: pend + 30 pfunc: does [return 
 now/time/precise]]
] "AGG progress pie"

3) How close to a working SVG renderer are we? ;) I'd really like 
to incorporate scaleable Icons, especially since the Tango links 
I posted previously have all their icons in dual PNG / SVG formats


So as SVG  master (yet again drunk ???? hum yes but that's last year 
night and first new year one so it's allowed to be hum lets say a 
little joyfull ) The answer is  easy SVG renderer is yet fully working 
as the matrix problem was internal to the VM and not to my code I 
simply need to disable the commented matrix line of code in my rendering 
engine and make the testing with the wonderfull, marvelous, extraordinary, 
free of bug version of REBOL/View 1.3.2 (?) The last issue is the 
gradient formating ...  and then we get a full 1 to 1  WYSIWYG svg 
rendering engine. This needs some testing too and some optimisation. 
You know me I seek first of all the full fonctionnality then i see 
if optimisations can be done to enhance the project (and in lucky 
rare cases my brain pop out a yet optimised solution but inspired 
by previous works like for listview widget wich was designed in an 
optimised way beacause of many inspiration projets were yet available 
 for this topic... )


For caret  system yes .... hum this remark was undirectly adressed 
to Carl we yet talked a lot on this topic on View Group last year 
 but it's good some time to recall previous unsolved discution and 
try to see if we can help Carl to change the design at least apporting 
to him some fresh ideas or only poping out why we found it really 
annoying based on our experiences and intents (like my mini ritch 
text editing widget using AGG to render the typed text  for example 
( see AGG group for code it's not long it's not fully working and 
it perfectly show as hard the handle of the caret position is!) .

For ppl interrested in  SVG rendering engine. My  tonight work  and 
 test on the engine   is resumed in the AGG topic. To resume before 
matrix bug as causing bad scale and bad position.  Now we have good 
position but still bad scale  i post screen cap samples and we can 
see that the evolution is good  betwin View 1.3.1 and 1.3.2

cool be cool to provide an AGG  based logo to be display in the about 
of the application well rebgui look and widgets are enought "original" 
to be recognized on every project that use them for initiate ppl 
...  but could be cool to get some way to attract users to interrest 
some ho on the  back ground

*Very* nice. I wouln't worry too much about how RebGUI complient 
you are at the moment as it looks like you are going to have to code 
a lot of it directly in View / AGG anyway! ;) Watch out Apple iCal 
...

I have done extremely advanced styles in rebol, including a video 
editing timeline with scalable time and slideable tracks,  and face 
can be extremely fast when its used properly.  The only issue so 
far was Draw speed (fixed with AGG) and slow face blitting (cpu based). 
 Otherwise, if your face is not full screen, you can scroll 300000 
cell tables 10 times a second... (yes with advanced styles and resizing 
and the like).

Excellent. If he can also have a quick look at SVG Renderer (SVG 
-> AGG) that would be good (scaleable icons / tool-bar have been 
blocked on this for a long time).

Me with the DRAW/AGG philosophy ( run faster allow to handle large 
kind  of documents  but  i really don't  know how to really handle 
the text cursor)  And  Coccinelle who represents the View phylosiphy

Just a precision, TDM Style use FACE capability to calculate the 
offset and the size of each items and also to for the caret <> offset 
mapping, but it use DRAW/AGG to display the result. Vectorial text 
is not supported. For this, we realy need the cursor managed by DRAW/AGG.

build#53 committed to SVN. Button widget rewritten to take full advantage 
of AGG and fix some anomalies (e.g. actions now fire on button up 
instead of button down, replaced 'active facet with options [info], 
hover effect no longer "sticks" when a popup is called from a button, 
etc). And all this in 1/4 of the code! ;)

re: chevron. You'll also be glad to know that chevron will re-emerge 
as an option of arrow. The previous implementation didn't take advantage 
of AGG's new line-width command,and duplicated much of the code found 
in arrow anyway. I'm putting RebGUI on a diet and trying to remove 
some of the "fat" that has managed to creep in. ;)

On another topic, I often find I need symbols such as those in a 
music player (stop, forward, fast-forward, etc) and in lieu of a 
cross platform "symbol" font I'm thinking that a symbol widget using 
AGG might be the go. Would work something like:

	display "test" [
		symbol data 'square
		symbol data 'arrow-right
		symbol data 'double-arrow-right
		symbol data 'circle
		symbol data 'circle options [no-fill]
	]


so the two questions are; would this be useful, and if so what would 
constitute a good set of symbols and names?

will you guys build downloadable file once you reach merged and kind 
of stable release?

 Last stable build is #46 available via the View desktop and here: 
 http://www.dobeash.com/download.html


Once the current changes "settle down" (i.e. at least a week or so 
passes without a major new issue/problem) I'll update the stable 
set.

161kB.. it's pretty large
 ... 30+ widgets tends to do that! ;)

I like the BTN style of button which is in Rebol by default

 ... Come up with an AGG (not image-based) equivalent or similar and 
 I'll gladly use that.


re: tabs (and button) look. My previous goal was to try and map the 
look as closely as possible to WinXP. This required a combination 
of images and complex draw commands. My goal now is to keep it as 
simple as possible, with a nice clean look that can be implemented 
with as few effects/draw commands as possible. Button is an example 
of that. Instead of using 3 images and changing them based on current 
button state, I now use a simple draw block and change a single value 
based on state. Note that the radius is customizable (via effects/radius). 
Does this produce the best looking button ever? No. But don't fault 
the technique, rather my [limited] AGG compositional skills! Feel 
free to come up with a better button algorithm.


tabs are another example, where yellow lines of varying length were 
drawn to approximate the WinXP tab look, and had to be cleared and 
redrawn based on state changes. The new approach uses a simple effect 
block ( [round color 5] )where all that needs changing on a state 
change is the color. Same deal as button applies. Come up with a 
simple draw block that creates a good looking tab and I'll gladly 
use that.

Vladimir - actually no - gob! is very low level, structure. Demos 
of former alpha, e.g. 1000cows, proved that R3 engine is much faster. 
Sometimes 10-20 times. Whole rendering back-end was switched to AGG 
renderer. So - still not HW accelerated, but decently fast.

In theory, it would be easier to hardware accellerate AGG than the 
old View.

Geomol: in this case, you're drawing them with AGG. Your text is 
not selectable.

Yes, in that one I used AGG to scale and composite a relatively low 
number of frames, zoomed to different distances.

Uhm, as I posted in Linux group, many systems are targetting its 
future towards vectore usage. Co-author of KDE 4 blogged about how 
fast Qt 4 based vector pipeline is, and it seems other engines can't 
stand the competition. Of course he generated some noise, as Cairo 
fanboys did not like it :-) http://zrusin.blogspot.com/So I looked 
at http://www.antigrain.com, to see what is new with AGG. It seems 
to me, that it is not good for RT - they are changing licence for 
any new version to GPL

Also if I understand correctly, Maxim has now full time job, non 
AGG related. I wonder what the future of AGG is for us, and if we 
should not look into something else ....

Pekr: The 'old' licence for AGG 2.3 and 2.4 remains. GPL is for 2.5 
which is at the moment at the same leve as 2.4(regarding functionality). 
So far noone from the AGG comunity(or at least at the ML) don't know 
why Maxim decided to change the licence.(everyone is waiting for 
his reply)

Maxim also wrote "Current AGG users who are willing to continue using 
AGG under the old terms and conditions are encouraged to contact 
me and I will consider their requests." so nothing is lost if we 
would like to use 2.5.

Anyway, even the AGG2.3 framework is very stable and have 99% of 
the features same like 2.4 and up. The whole code quality is very 
good so it is possible to enhance it...so this shouldn't be a big 
problem for Rebol.

Another thing is that in the 'worst case' current AGG users/developers 
who don't want or cannot use the GPL version are planning to continue 
with improving the 2.4 codebase separately.