World: r3wp

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 :)

cool :-)

Cyphre, I'm very glad to hear that you're still working in REBOL 
:)

How it's with AGG and R3? Current REBOL version is using AGG version 
2.3, which has copyright message:

Anti-Grain Geometry - Version 2.3 
Copyright (C) 2002-2005 Maxim Shemanarev (McSeem) 


Permission to copy, use, modify, sell and distribute this software 
is granted provided this copyright notice appears in all copies. 
This software is provided "as is" without express or implied

warranty, and with no claim as to its suitability for any purpose.


The AGG version 2.4, which is basicaly same as version 2.5 has copyright:
Anti-Grain Geometry has dual licensing model. The Modified BSD 
License was first added in version v2.4 just for convenience.
It is a simple, permissive non-copyleft free software license, 
compatible with the GNU GPL. It's well proven and recognizable.
See http://www.fsf.org/licensing/licenses/index_html#ModifiedBSD
for details.

Note that the Modified BSD license DOES NOT restrict your rights 
if you choose the Anti-Grain Geometry Public License.

Can we update the REBOL's Agg sources to the 2.4 version to be used 
with open sourced host-kit?

I got 'yes' from the AGG author to be able use v2.4 but there is 
not much significant changes in 2.3 vs 2.4 except internal code cleanup 
and few new custom rasterizers so the priority for going to 2.4 was 
never high enough to spend time on it.

The AGG in R3 uses some code from 2.4 as it was much easier to add 
it this way than merge all the custom changes to 2.4 and then do 
all the testing to see if something went wrong.


Ofcourse any effeort to make the proper transition from the current 
2.3 based code to v2.4 is welcome.

Is there any graphics related test framework?

AFAIK There is no real test framework for R3. Only the DRAW and SHAPE 
tests included in host-kit.