World: r3wp

wrt freetype... only TrueType font rendering has any kind of patent 
issues... so if you use other type fonts you're ok.

However, in theory you paid those license fees to Microsoft if you 
run Windows 7, and to a lesser extent earlier versions. The MPEG4 
fees could be thought to be covered by Apple if you run OSX, which 
includes Quicktime. Don't know the law well enough to know whether 
the license requires that you use the licensed code, but patents 
cover the method (the idea), not the code (the implementation).

Aren't most fonts OpenType nowadays? Those use the TrueType methods, 
afaik.

don't know really.  but in any case, you don't have to use the library 
to do the rendering...  We can always render them using AGG or OpenGL. 
 as long as we have the coordinates.

Is it possible to save a ppng image with transparency (actually translucency)?

png

Fast test show, alpha is saved. This could be a new thing in R2 2.7.7, 
as I seem to remember, this didn't work before!? I did this:

i: copy logo.gif
i/alpha: 128
save/png %logo.png i


It seems, the saved alpha is 1 higher than what I set. I tested with 
PPC version of R2 2.7.7 under OS X.

Btw. I don't think, this belongs in this group, as it isn't directly 
related to AGG. Or did I misunderstood you?

I did not see a draw group

Which I thought would be appropiate

Well, AGG and DRAW isn't used in my test. It's plain REBOL. It would 
even work with REBOL/Core, I guess. (I know, graphics in REBOL can 
be confusing.)

But try do something similar as my example and see, if you can save 
the alpha channel in PNG images.

I asume the alpha is already in the logo...I'm trying to build a 
translucent box using draw (for use in a web page) and save it in 
png.

ok, maybe we can create a simple example of that.

Hang on

ok...that looks like it worked...thanks much, Geomol

Welcome.

Another example:

img: make image! 100x100
img/alpha: 255	; making it transparent

draw img [pen none fill-pen 255.0.0.128 box 10x10 60x60 fill-pen 
0.255.0.128 box 40x40 90x90]
save/png %box.png img


Two boxes are drawn on a transparent image, one red one green and 
both with 50% transparency, and the result is saved as PNG.

Thanks

Does anyone know how TRANSLATE works internally? I'm experiencing 
quite some slowness when using it on images.

corner: 0x0

; fast
draw-block-1: [
	image img corner
]

; slow
draw-block-2: [
	translate corner
	image img
]

the image is not meant to be processed for scaling, but only for 
panning and therefore, draw-block-2 should be about as fast as draw-block-1, 
but this is not the case.

http://rebol.hmkdesign.dk/files/r2/draw/drawbug.r

Reproducable in OSX and WinXP.

I have discussed this with Henrik already but reposting here so anyone 
knows.
This is actually caused by one 'optimization' feature. 

Currently if you are not changing the transformation matrix the engine 
uses faster routine for image rendering bypassing the image filter/interpolation 
code.

The decision is based only on simple fast test if the matrix have 
changed.

So to make it 'smarter' we need to improve this optimization decision 
condition so it checks if there was only scale/rotation applied to 
the matrix and ignore the translation changes.

Then it will use the faster rendering also for simple translations 
without scale/rotation.

This would be very usefull for me.  If its doable for the next R2 
release... I'd appreciate it  :-)

don't dream :(

Plus, If the the interpolation process is based on matrix calculus 
only. There will be ne no gain.

I mean a simple translation can be seen as a matrix as well and it's 
probably how it"s managed.

but what Cyphre describes is that there is a way to simply blit the 
pixels, if there is no interpolation, which is MUCH faster (just 
try the little drawbug.r script above to see the difference)

If I understood correctly what he meant. There is an unique transformation 
process (unsing matrix calculus). The same matrix mix all the effects 
(translation, rotation, scaling)

That's why I think there will be no gain if translations can't be 
processed separatly

there will be no gain when scaling and rotation are ALSO applied 
to the transformation.


but if there is ONLY translation, then there is no need for any interpolation 
or matrix calculus... just a simple blit as if you do:
draw [ image my-image 30x30]

Steeve: by looking at the matrix it is very easy to see that there's 
only translation.

Yeah but that was not my point, (I failed to explain it clearly I 
guess)

Yes, Gabriele and Maxim got what I meant to say. Steeve, not sure 
what you mean.

Basically It is possible to add any code that analizes current matrix 
state at this point but I guess simple check if only translation 
was applied will be easiest, fastest and suit majority of cases.

Regerding R2 releases: Sorry, I'm currently somehow 'out of the loop'. 
I don't know what is the plan, how are the releases organized etc. 
I even don't know if any DRAW improvements are wanted right now. 
But I'll try ask Carl on R3 chat.

So, it's a good time to make a comment on it...

The plan is quite simple: to move the graphics dialects into "resident 
extensions" (almost an oxymoron, but I will explain it.)

One of the most important purposes of the extension model is to isolate 
extension code from REBOL internals. That way, internal revisions 
won't require extensions to be changed.

So, the first step is to modify the dialects such as DRAW to use 
commands for each "function". This also makes it easier to create 
auto-documenting code.

The entire goal is to get the graphics back into the hands of Cyphre 
and anyone else that wants to help on it, and also to allow them 
to expand and change it without needing to recompile R3.

Now, about "resident extensions" that's simple: it's just an extension 
that is resides in the host part of the exe.  It should not take 
much to do that (mostly docs.)

Carl,  sounds like a good plan.  How far along is it or is it ready 
to be worked on?

I'd like to get some "test code" out by Monday, if all goes well. 
It may break a few things in graphics... but we can adjust it.

Well, Cyphre was talking about R2, and Carl is talking about R3 apparently. 
But anyway - will change incorporate merge of command and DELECT, 
so that it can be generally used by extensions, as planned? (there 
are still some wishes for improvements to extensions in CureCode 
or R3 Chat I think)

Carl, that R3 plan sounds good. Ping me anytime you have some code 
to test.

Cyphre - how's your JIT doing? :-)

JIT ?

The existing R3 extension model alows you to write JIT-compiled dialects 
in REBOL.

Pekr, the JIT dialect for R2 is nearby alpha stage. Watch out the 
announce group for more info soon :)