[AGG] to discus new Rebol/View with AGG
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.
ok...that looks like it worked...thanks much, Geomol
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.
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? :-)
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 :)
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.