World: r3wp

Yes, I have a demo that Cyphre gave me.

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

Is there a performance-difference in using the old face/image or 
 drawing images in the draw-block?

using face/image is definitely faster

Is there a way in Draw/AGG to globally set TEXT rendering mode (aliased, 
antialiased, vectorial) instead of setting it each time you  call 
TEXT ?

The ANTI-ALIAS command doesn't seem to have any effect on TEXT rendering. 
Odd, the docs says otherwise : "The ANTI-ALIAS command currently 
affects the entire DRAW effect; the last value you set it to is what 
will be used for all draw commands in the block".

IIRC anti-alias affects only  vectorial text, not the standard one

Dockimbel: You have to always specify the TEXT rendering mode. Maybe 
the text mode could be set by separate command in later versions? 
The ANTI-ALIAS command works for all vectorial shapes and doesn't 
affect TEXT in other than vectorial mode. (the docs needs to be fixed 
in this case)

Cyphre, can you tell us what changes will bring the next Draw/AGG 
releases ? Wider font support ? Dialect improvements ?

Once the Rebol/View code merge will be at the level of View1.3.2 
we can add some bugfixes from RAMBO. I'm not sure how much new features 
would Carl like to add to R2 DRAW but I believe there will be at 
least improved and enhaced gradient support. What  else DRAW changes/features 
would you like to see in the upcomming R2 releases?

(ah, I forgot that we might also add new image filter so you can 
make hi-quality thumbs ;-))

yes!

What filter?

I would like to be able to work with images on linux server without 
X server running

without that I'm still forced to use PHP for image uploads

I'd like to have better font support (most of Windows TT fonts seems 
to not work), better font objet support (things like 'offset and 
'valign doesn't seem to work), persistent Draw settings (like Text 
rendering mode). These font issues may be due to my lack of experience 
with the new Draw/AGG, did other ppl had the same issues on windows 
?

Oldes: you could make a REBOL wrapper around the GD library (used 
by PHP for image processing).

Oldes: I meant image filter with resampling so when you downscale 
image the result is much better(but costs more CPU time) than using 
bilinear filtering.

I cannot. As I have only Pro licence. Cyphre - if it's not working 
on server - it's useless for me. At home I can use image magic. But 
I know, that's not your fault.

running DRAW without Xserver. This is quite possible but it all depends 
on Carl's decission in which product he want to have it. AFAIK the 
DRAW native command is in Rebol/Command(which can be run without 
Xserver) at the moment.

I believe this will be improved in R3 with better modularity.

Well...after doing some more testing on fonts, looks like it works 
correctly with all TT fonts I've just tested. I used to never set 
the rendering mode for TEXT, maybe that was the cause of my issues.

Doc: the FONT rendering in R2 DRAW should handle all TTF fonts. (at 
least I havent heard about any problems from anyone). The persistent 
text mode can be added IMO even in R2. Text formating won't be probablay 
enhaced as this would take too much effort. But in R3 there will 
be rich-text dialect for that purposes. (Maybe the new rich-text 
dialect  could be backported into R2 later but it all depends...)

Cyphre probably remember I still would like to have bitmap fonts 
(use specified parts of image as font glyphs:-)

eeh, that debate indicates, R3 is at least one year from being findished. 
Other than that - what would be the reason to backport anything to 
R2?

Cyphre - how Carl's decision of where he wants to put draw can be 
valid for R3? Or are you talking about R2 here? I thought that with 
R3 the rather stupid product segmentation vanishes once and for all 
...

Pekr, the reason for backporting is that: 1) there will be high demand 
from R2 userbase for such feature 2) it would be easy to do it. So 
my note above is very hypothetical ;)

well, it is just that we talk about R3 as of a beast, not being compatible 
more than from 30% to R2. If it is going to be nearly 100% compatible, 
than continued development of R2 after R3 release is total vaste 
of resources .....

Pekr: I have no clue about the R3 product line/strategy, yo need 
to ask Carl about this. (I guess from Carl's blogs there will be 
more flexible aproach to build your 'own Rebol' than in R2)

yes, that is also my understanding. So /draw will be module, which 
you will be able to "include" (pack) into your exe. But that alone 
does not probably answer, when/where X-Win is needed?

AGG based DRAW is platform independent so it doesn't need X-Win or 
any other API framework. The only dependent part is TEXT rendering(which 
is not included in the AGG). Currently it supports Win32API and FreeType2 
library to be able render text. So even if you have rebol on Linux 
you only need freetype2 lib, not Xserver in your setup. (the X-win 
dependecies are in the older Text rendering engine of R2 used for 
text in faces which will be eliminated in R3).

I'm curious, what kind of font rendering does View use?

I noticed that View produces pixel artifacts on some letters on my 
PC, but I think that's RAMBO'ed. Those artifacts are not visible 
in DRAW text.

Under what OS?

XP

I think it's only visible with clear type enabled

http://bolek.techno.cz/pix/view-artifacts.png

yep, those

Hmm, iteresting. I have the cleartype turned off so I didn't know 
that. That looks like something is going wrong with the cached glyph 
bitmaps when BOLD text is used with cleartype enabled. I don't know 
the guts of old text renederer so this is just my guess.

clear type is very different in how it treats pixels... it actually 
addresses each individual  R G B channel of each pixel individually, 
so what happens is that on many faces, the anti-aliasing actually 
turns the edges as shades of colors, and not gray.

the downside is that this is optimised for working on white BG in 
all I can see, and is obviously useless unless you have an LCD monitor.

I've only noticed the artifact in rebol when text is bold... don't 
know why.

my guess is that REBOL builds its glyphs once and then any PIXEL 
that has one of the channels to on is set as all on... so we get 
bad aliasing and some dots here and there.

AGG wouldn't have this effect since it does not seem to use clear 
text.  in fact, in general I find AGG font AA pretty ugly... is there 
a way to improve this?  even if its slow?  there are some situations 
which do not mind speed (generating HQ output graphics, for example) 
 or small GUIs or when converting face looks to bitmaps before display.. 
(trades speed for ram)

Maxim, I don't know. The output seems pretty similar to what is output 
with Freetype 2, but the AA is a little uneven, yes.

I find the issue is mostly with thin lines where the aa will be quite 
spectacular in its variations  especially if you look at the difference 
from 45 angle and near 0 or 90 degre angles. I know that AA should 
be an energy based repartition, which is not linear.  (gamma) such 
that two pixels at 0.5 are actually a quarter as bright as one full 
1.0 brightness pixel to our vision (obviously subjective to user 
response, applied monitor gamma and superwhite levels, etc).

for example, if you want to slide a picture of a stars, you must 
first boost the gamma of the picture by 2, do the move and then apply 
a .5 gamma.  then, the AA will have spread out according to energy 
rather than color.  which means that the 2 side-by-side pixels will 
be at much more than 0.5 of the original 1.0 single pixel brightness.

so I guess a similar operation is needed for fonts (I have no concrete 
bg in fonts, only view a similarity)

I also know that apple, quantel, adobe, MS and others have patents 
in font, and AA algorythms, which might actually prevent people from 
performing proper AA or Font rendering... even if they know how.

The AA is the reason, why I want bitmap fonts. With such a bitmap 
it would be very easy to create pixel fonts. If you take a look at 
Flash you can see, that most of the sites is using pixel precision 
fonts, which are made for fixed height but anyway are much more smaller. 
http://fontsforflash.com/