AltME groups: search

maybe Cyphre did some changes in AGG ...

anyway - 2.4 AGG is stop gap for us ... Maxim decide to release 2.5 
under GPL ...

agg changes in 2.7: most of the dialect changes/bugs are probably 
because of the internal string change Carl mentioned. i don't know 
of any major changes by Cyphre.

Yes, Gabriele is right. No big changes to DRAW at the moment. We 
wanted  to make sure the new compiler and string change doesn't break 
any actula feature of DRAW so the decission was no changes to AGG 
until we are sure it works the same like in 1.3.2.

elixir creates several thousand line AGG blocks and it just hammers 
away.

but the main limiting factor is still view refresh speed (view and 
AGG that is)

yes... there is something weird with the port management.  as I said 
a part from that I've had no bug a part from a few AGG problems.

its also possible that with the AGG fixes done or pending, we might 
get a 2.7.8 beta which has current mezz code and the bigger native 
changes pushed to a 2.7.9 release... but I'm just throwing a guess 
in the air.

is there the possibility of getting R3 AGG Richtext dialect backported 
to R2 - it would make a huge difference for gui development and text 
rendering?

I could be wrong here, but I think "flood" is from the "old draw", 
and I don't remember if it was supported when R2 moved to AGG for 
draw.

I just seem to remember a discussion about flood when R2 moved to 
AGG, but I don't remember the details. in general though should shold 
be able to achieve the same effect without using flood, and it is 
probably going to be faster.

ICarii: see the first sentence in the doc page you refer to: "Describes 
the original draw dialect - for historic reference..."
So yes, FLOOD was only in 1.2 View (pre AGG DRAW) .

Gabriele is correct, it was not implemented when we got the AA gfx. 
Geomol did nice and not so slow flood-fill in RPaint IIRC.

If you really think it is valuable to have FLOOD back and show Carl 
some good small enough routine that could be used he might add it 
as he is currently 'open' for smaller R2 Draw improvements.

they = AGG fixes (mainly one which crashes AGG if using several gradients 
in the same block).

I discovered the bug while typing in a text field and the color of 
the field changed whenever I typed in a space!


It took me a while to realize it was a problem in AGG and not in 
my code... :-)

correcting the agg bugs in r2 ? i would like antialiasing better 
fonts more readable less bug around the handling of font fixed etc... 
but as it just conserns my particalr and singular needs and as noone 
likes me i think i can forget it .... a bugfix to agg matrix  would 
be  nice too .. I know i'm such an egoistic being etc ...

it seems the AGG text bug was not pushed to the 2.7.8  release...

Max - thas is something I don't agree with - turning whole View into 
3D model. You should talk to Cyphre. AGG is pixel precise, 3D stuff 
can differ per GFX card, per driver version. I would accelerate only 
blitting.

but Glass will be built exclusively using OpenGL... its going to 
be vastly superior to AGG in what it can do.  never mind pixel details... 
we will have millions of concurrent objects on screen all in real 
time.

Geomol - Cyphre told me, that you could map parts of AGG to HW acceleration, 
but then it can look differently on each gfx card/driver ..

well, noting that all OGL antialising is about 2000 times prettier 
than AGG's  I don't mind  ;-)

It is? :-) I thought, AGG did a pretty good job.

in any case, when you build a GUI with OGL, you build in such a way 
that everything scales, cause its sooo easy to do... its in fact 
free... like AGG.  so the fact that a GUI isn't exactly pixel perfect 
is secondary... since often you don't even have the same fonts on 
various OSes  ;-)

there is a big difference in how flash and AGG render their stuff.... 
it seems to me that AGG is actually more scalable in sheer quantity 
of strokes, whereas flash seems to be much better at handling textures 
and bigger screens... have you noticed the same reactions... having 
much more in depth knowledge of flash, I'm curious as to your observations....

I don't know AGG well so I'am not able to compare these. AGG can 
use same rasterization as Flash (which is more optimized for speed 
I guess). At least that's what Cyphre told me.

Cyphre has thought that we might switch to "compound rasterizer" 
of AGG, which would be more similar to Flash. But we might be slightly 
off-topic here :-)

GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.

programming for a 3D rendering engine and for a scene engine is a 
totally different affaire... just like using DRAW vs using AGG directly.

so Ogre is in 3D kind of what AGG is for use in 2D - an cross platform 
abstraction?

I wonder how well does REBOL work with such kind of stuff. What will 
you use? Kind of direct linking to functions? Or kind of dialect 
abstraction as we use for AGG (draw)?

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

one of the reasons I want to use objects directly within extensions 
is that I am noticing GC recycling interruptions while scrolling 
stuff in R2 AGG driven interface.

if you can add some object reference to the hostkit, I'll be switching 
over all of my tools to R3, may even help with low-level AGG, and 
finally start forgetting about R2.

as an example, we could just represent a draw structure using primitives 
as objects (which can include several AGG primitives) and call AGG 
native code directly from the object tree.

something like 
draw context [
	prim: 'cross-box
	offset: 10x10
	size: 20x20
	thickness: 1
	border: black
	cross-color: red 
]


would draw a box and two cross lines, without the need to reduce 
this at every refresh when its refreshed and data comes from external 
manipulators:

draw compose [
	pen (prim/border)
	fill-pen none 
	line-width (prim/thickness)
	line-pattern none
	box  (prim/offset) (prim/offset + prim/size - 1x1)
	pen (prim/cross-color)		
	line (prim/offset) (prim/offset + prim/size - 1x1)

 line (prim/offset  + (prim/size * 1x0)) (prim/offset  + (prim/size 
 * 0x1))
]

yes... but they also allow context on the REBOL source side.


note that with the example above using objects, I don't need to go 
thru a draw block on the native side.  I could inspect the object 
and fire AGG (or other lib ;-) commands directly

For the human side, such as providing a style sheet containing graphics 
attributes, object is the winner. However, as that style sheet is 
processed, it is flattened into a sequence of commands sent to the 
AGG rendering engine.


Now, it's probably possible to change our API into AGG to use objects, 
and that's probably find, but I'm not sure that it's really any more 
efficient.

true, but objects can be nested. and a single small object, like 
in the above, may actually represent MANY draw commands.
 

for example... a single block of text strings... may actually represent 
all the items of a text list.  parsing that list to fit things within 
bounds. 

re-creating the whole AGG block as you scroll the list, forces you 
to possibly generate a few hundred draw items in a block.


but you have to build that block using intepreted code, which only 
ends up being an intermediate in order to pass the visuals to the 
rendering.


with an object, constructing that visual can all be handled on the 
native side and will save a lot of work on the interpreter and the 
GC.

steeve, right, because in R2 there is other way to make a 100% AGG 
interface.

in R3 I could go far beyond, actually dumping some of liquid's processing 
directly in the native side of an extension.


in fact, I could use AGG or OpenGL directly without even using gobs 
or draw blocks since the interface is built by how you link things 
together and this linking and messaging will automatically fire-off 
AGG commands, without the need to go through an intermediate.

Someone know why we are still using AGG 2.3 from March 2005?    2.4 
still used the BSD license

( Unless QT is wrapped .. like AGG is )

You probably can't wrap Qt like AGG. It would be easier to wrap R3.

For instance, in the AGG wrapper the commands that are used to implement 
the Draw dialect are exported in their own context rathar than globally, 
because they aren't meant to be called directly as functions. Other 
APIs may need to do the same thing for similar reasons.

If this is the issue there are two solutions.

1. even now you can set the transformation matrix for example using 
MATRIX command(or other matrix related commands)  to change that

2. internally in the AGG code there is a way how to change the order 
in which the scanlines of the framebuffer are rendered in the Y-axis. 
In other words you can flip the Y axis.

Gregg sorry actually  i'm very very sick ... i spent past week after 
our interresting (what was the word damn ...) "flow of nonse" (maybe 
i don't remember and i'm too tired  to remember anything)  in bed 
spiting my pulmons to the floor...  so i think i'm out for another 
week and if eventually i'm not dead at the end of next week i will 
try to send some ideas .... but basically i would say if it's not 
dark grey and  flat it's ok will me .... we use AGG for the gob design 
and rendering this allow us some creazy stuff that will promote the 
new VID and make it apealing .... VID gui never seen before but not 
because they  are super ugly  and all childish with glowing primary 
colors ....

think that agg can offert us really creazy effects motions shape 
changes solidity changes.... etc.... so for me the perfect gui Lib 
would play with those aspect in a clever way and maybe be the base 
for people to say ok .... and what if my next application would be 
a cloud ... a cloud have a non definited shape you can cut it in 
pieces than rearange those pieces you can make some part more dense 
some other part lighter   you can shrink it or completly change anytime 
it's shape .... the kind of interface that would be just  so fun 
to exploit use a multi touch screen ...

well, did you see the images?

henrik (and I) did a few aqua-esque AGG driven buttons.

but the material (gradient) is still represented by draw, right? 
I mean - there is no chance for designer to e.g. use some gfx tool, 
to create some nice material, as it is not convertible to AGG, right? 
Or would there be any way, via SVG for e.g.?

another question.  if I have a region of ram which contains rgba 
pixel data as an array.    what is the function I need to call within 
the compositor::cp_process_gobs() func so that I can copy that array 
within a gob's pixel buffer?


I've been running around the source and its a bit complicated... 
there are so little comments in the agg code... I'm not sure what 
does what.


I was thinking that the clue lies somewhere in the undefined code 
within 
case GOBT_IMAGE:

but is the code for copying over image data to the compositing buffer 
basically there?

mainly:
	ren_buf m_rbuf_img;
	m_rbuf_img.attach(GOB_BITMAP(gob),gobw,gobh,gobw * 4);
	agg_graphics::pixfmt pixf_img(m_rbuf_img);
	[...]
	m_rb_win.copy_from(m_rbuf_img)

Yes, this is not so easy to do as you need to always manage the window 
differently for almost every gfx system. I have in works AGG accelerated 
using OpenGL using one trick which makes things much easier and still 
pixel precise. But I need to try convert the pure c++ prototype code 
into the Hostkit first to see how it behaves in 'real world' usage 
cases...

yeah, without some support libs, designing shader stuff from scratch 
is hairy at best...


the only help I can give you is to use light energy-based math instead 
of color math.  I've seen some VFX compositing tricks where  you 
can simulate this by scaling colors with a gamma of 2 blending your 
colors and then applying the inverse gamma of 0.5.  the way the colors 
will merge usually provides better results, but still doesn't clip.


the idea here being that the gray areas won't merge the same way 
as low and high-color areas... might be usefull to play around with 
gamma in the draw block too... though I'm not totally sure how it 
all works in agg.

it goes beyond that... at the purely language level R2 was really 
limiting many things I wanted to do.  view and AGG limitations where 
also very present in my tests.

But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch

At this point, the only plans I have heard people making for Android 
were to make an R3 host that would act as a plugin for the Android 
native API model, so that R3 would be a native library to supplement 
apps that are primarily written in Java. No talk of AGG yet in those 
plugins though.

Android can do SDL, so it should be able to do the host kit and AGG, 
in several ways

I have zero experience with Android but from what I read here I can 
guess what is needed:

-R3 should be ported as native Java plugin including the agg (in 
C/C++)

-we should write Andriod OS compatible Java based application wrapper 
which will include basic app event loop, window+framebuffer management, 
networking+file IO (?)

-this Java wrapper will be able to open window, detect all the OS 
events etc. and pass it to the Rebol plugin

btw... many host-kit fixes are pretty easy if you know where to look... 
for example to enable image gobs in Carl's host-kit, one must just 
remove the temp_remove and replace:
	int gobw = GOB_CONTENT(gob)->size & 65535;
	int gobh = GOB_CONTENT(gob)->size >> 16;
to:
	int gobw = GOB_W(gob);
	int gobh = GOB_H(gob);

https://github.com/rebolsource/r3-hostkit/blob/4d3bdeaa77cf1ec7c5d97738509ecec4fdf4b7e7/src/agg/agg_compo.cpp#L594


And that's all... I really wonder why you keep the host-kit updates 
hidden. Even Carl was able to put it on github:/

you display just what you draw using any graphic lib, like AGG at 
this moment.

oldes glut is compact, it's C based, it's portable on linux, windows, 
macosx only 117Ko and it opens a big gate to opengl since that's 
it's main purpose... Agg could be adapted at some point to use hardware 
accelerations proposed by OpenGL API at some point or at least we 
can investigate that part... Glut is old so this means it's super 
documented, and glut goal fits what r3/GUI basic goals are manegment 
of windows and management of user's inputs

I really would like it if Carl could fix the event port so that it 
lets all resize events go to the even handlers.


right now, the graphics code has access to it, (because you can see 
the AGG gobs refresh when the window resizing) but the REBOL event 
handlers receive only the last resize event.  which means we cannot 
resize the view while its being dragged.

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

I am not sure it is realistic to get gfx going under the Amiga for 
the Amiwest. OTOH IIRC AmigaOS has ported AGG already, so maybe we 
will be lucky :-)

Pekr, I bet the AGG part will be easy to compile on AmigaOS. I compiled 
AGG on quite few platforms and it went smooth. IMO More work needs 
to be done on the event loop and window management in this case.

Considering I was the one who ported AGG to Amiga I don't think it 
will be a big issue... :-)

I've one more tip on the way of getting started with AGG: A109 has 
a stupid typo in it.

it allows you to hook up alternate graphics drawing within AGG or 
directly on the window which view opens.  though you still have to 
map all that nasty OS specific windowing event stuff first.  keep 
in mind that you might be able to do stuff like a datatype viewer 
right into the view engine  :-)

Is there a version of the host-kit that works with AGG without Windows?

ssolie: the only file that needs to be reformatted so it supports 
other platforms than windows is agg_truetype_text.cpp + .h

Otherwise there is already available FreeType wrapper so the rest 
of code can work  even on OS4

But the current hostkit code needs some more work to extract the 
font/text rendering parts so they can be controlled by defs.

If you don't want to waste time on this I can have a look at it over 
the weekend and make the changes so you should be able compile without 
the text code for now. Just let me know.

I just got compositing working on the Amiga (via AGG).

Pekr: AGG is very quick  which is why it renders so nicely but it 
is all CPU bound (no h/w accel) -- I would appreciate a benchmark 
because I think we should be compiling AGG with -O3 given it is C++ 
code heavy on templates

Is there a way how to force REBCHR to be in multibyte format? Because 
the problem for the above issue is at this line:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/agg/agg_truetype_text.cpp#L305

Yes... but AGG requires multibyte. Probably. At least I can display 
gob with non ansi string like:
	g_text: make gob! [size: 100x20 text: "èøž"]
but not:
	g_text: make gob! [size: 100x20 text: "crz"]

I'd be surprised if AGG couldn't work with UTF-8, and that wouldn't 
be the default on Unix

I don't know, but know that I need wchar at this point and don't 
have it:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/agg/agg_truetype_text.cpp#L696

Mistake - extensive ansi text will be affected as AGG is using widechar, 
each ansi string which we want to display in view must be converted 
to wchar on each redraw!

Does AGG have separate 8bit and 16bit rendering APIs or is it always 
one or the other?

If it is UCS-2 or UTF-16, then all that would need to be done is 
to convert UCS-1 model R3 strings to UCS-2 mode somewhere before 
rendering. (He says glibly, having not analyzed the AGG sources or 
APIs.)

I'm still guessing this only applies to AGG on Windows, using UTF-16. 
On other platforms, AGG uses FreeType, and I guess that would accept 
UTF-8

I think the file you're looking at is not really part of AGG, but 
written by Cyphre as a bridge between AGG and Windows

Btw... it's the reason why I'm hacking the code... I would like to 
enable bitmap fonts. AGG supports that, but I don't think that Cyphre 
has enough time to work on it alone:)

Unfortunately instead of experimenting with agg itself, I must solve 
issues which are already solved but not public yet.. but at least 
I'm learning.

steeve, with layers, I split up the rendering into different things. 
  bg/fg/interactive.  and I don't have to render the bg all the time, 
only on resize. 

I'll also be able to render just a single widget directly on a bitmap, 
using AGG clipping to that widget.

The interfaces between REBOL and AGG are rather REBOL specific. I'm 
not sure it's worth it to try to use them in Red

Cyphre says that it's easily possible to use the AGG part outside 
of R3.

License is a question for Carl. Perhaps it's simpler to just interface 
AGG directly. Not sure.

Well, latest AGG version (2.5) is distributed under GPL, development 
has stopped in 2006, it doesn't support hardware acceleration AFAIK, 
so it's a no-go. Cairo seems like a more modern graphic vector engine. 
Anyway, it is open to any contributor, as I don't plan to work personally 
on a View-like engine for Red.

2.4 is BSD. 2.5 is only slightly improved. A residual community around 
AGG has been continuing with 2.4 and has made a few fixes to it

http://agg.svn.sourceforge.net/viewvc/agg/

There are basically four options: AGG, Fog, Cairo and Skia

AGG and FOG may perform better, but I'm not sure. The choice between 
those two is difficult. AGG is basically abandoned, but still more 
popular than Fog

I'd like to know how it compares to AGG and Skia

I also want to know if rendering quality in Skia is as good as in 
AGG. It sucks in Cairo, or at least it always did. Fog is likely 
to be as good as AGG, because it builds on the same principles