r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[AGG] to discus new Rebol/View with AGG

Steeve
26-Feb-2007
[890]
IIRC anti-alias affects only  vectorial text, not the standard one
Cyphre
27-Feb-2007
[891]
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)
Dockimbel
27-Feb-2007
[892]
Cyphre, can you tell us what changes will bring the next Draw/AGG 
releases ? Wider font support ? Dialect improvements ?
Cyphre
27-Feb-2007
[893x2]
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 ;-))
Henrik
27-Feb-2007
[895]
yes!
Oldes
27-Feb-2007
[896x3]
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
Dockimbel
27-Feb-2007
[899x2]
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).
Cyphre
27-Feb-2007
[901]
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.
Oldes
27-Feb-2007
[902]
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.
Cyphre
27-Feb-2007
[903x2]
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.
Dockimbel
27-Feb-2007
[905]
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.
Cyphre
27-Feb-2007
[906]
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...)
Oldes
27-Feb-2007
[907]
Cyphre probably remember I still would like to have bitmap fonts 
(use specified parts of image as font glyphs:-)
Pekr
27-Feb-2007
[908x2]
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 
...
Cyphre
27-Feb-2007
[910]
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 ;)
Pekr
27-Feb-2007
[911]
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 .....
Cyphre
27-Feb-2007
[912]
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)
Pekr
27-Feb-2007
[913]
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?
Cyphre
27-Feb-2007
[914]
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).
Henrik
27-Feb-2007
[915x2]
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.
Cyphre
27-Feb-2007
[917]
Under what OS?
Henrik
27-Feb-2007
[918x2]
XP
I think it's only visible with clear type enabled
Rebolek
27-Feb-2007
[920]
http://bolek.techno.cz/pix/view-artifacts.png
Henrik
27-Feb-2007
[921]
yep, those
Cyphre
27-Feb-2007
[922]
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.
Maxim
27-Feb-2007
[923x5]
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)
Henrik
27-Feb-2007
[928]
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.
Maxim
27-Feb-2007
[929x4]
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.
Oldes
27-Feb-2007
[933x2]
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/
and if I can use such a image http://box.lebeda.ws/~hmm/rebol/projects/font-tools/latest/fonts/idea.png
to create glyphs which I can use in flash: http://box.lebeda.ws/~hmm/rebol/projects/font-tools/latest/fonts/idea.html
it would be nice to have a chance to use such a bitmap (or the vectorized 
glyphs) in Rebol as well
Graham
27-Feb-2007
[935x3]
Is carl going to release a linux sdk with agg enabled?
before R3 comes out ?
agg font support ie.
Cyphre
28-Feb-2007
[938]
Graham: I think the linux SDK will have agg enabled once we solve 
the font path identification thing.
Oldes
5-Mar-2007
[939]
How to rotate ARC?