> My concern about fragmentation is mostly about > getting the same behavior on all plateforms.
A concern I can very much understand and sympathise with. Ultimately, I think this needs one or more "champions" for each platform who are willing to actively involve themselves.
Is there any existing documentation around R3 implementation that would help any beginner to jump in?
Also, what's your opinion on using SDL2.0 as a R3 host ?
SDL 2 would be a good backend to add
It would be a good backend but at the same time I wonder if it is not too much. SDL2 handles video, events, files, timer, keybaord, mouse, simple drawing, ... and R3 does many of this already. Mostly the compositor is what we miss.
IIRC Robert had some interest to use SDL2 as replacement of some of the host parts. But I think this is not small project. GregP, you have good point about the SDL based compositor. That could be interesting to try, but IMO it wouldn't improve the 2d vector graphics cpu performance it that's what you are after. Also I haven't researched if the SDL is modular enough so you can use only specific parts of the framework to have small footprint.
I agree it is not a small project and I would not be alone on this. The main motivation to use SDL would be to port the host to some other OSes like Mac. Also, SDL is pretty well supported since version 2.0, that's another plus.
GregP, make sure you check out your private chat
Since we have R3 "view" on Win and Linux I'd personally like to find some time to finisih porting R3 "view" to Mac...there is only relatively small part missing so it should be much easier than doing the full SDL port.
-- Since we have R3 "view" on Win and Linux I'd personally like to find some time to finisih porting R3 "view" to Mac --
sounds much better than opening another SDL bottle, what do you need to find this time or increases your motivation,.money?
TomBon, what do you mean by another SDL bottle, can you clarify?
Cyphre, if you think we could collaborate on this, maybe you could guide us?
as stated above R3 is quite fragmented and adding another loosing end (SDL) doesn't help much. from my pov R3 is well positioned but needs a 'best of branch' unification. as cyphre said, adding the missing parts for mac could be done much quicker, therefore my question what is needed to do so. moreover, iirc R3 is already designed to switch backends (renderer?) later, e.g. agg -> cairo but since i am not deep into rebol atm i not sure at which state this whole thing is.
another thing, is it right that there are 3 major branches atm? original, attronix, saphirion?
is there a matrix avail. to see the diffs (e.g. +/- FFI / encap / call / patches etc.) without checking the sources?
we are slowly working towards unifiying the commercial Rebol Branches .
There will be phases to this unification and there will be several people from various groups, able to accept contributions. Note that we encourage the community at large to contribute, and when acceptible, these will be rolled in the next version.
Pull Requests will be reviewed by different people from different companies which have large code bases. The idea being that R3 needs to get stable at this point. there needs to be more collaboration and this is the first step.
We are moving ahead steadily, taking many steps to make it work. we are already 6-7 companies depending on how you count things and will be building up the project for all of november. I am aiming Dec 1st as a release date for public launch.
I wasn't going to go public too much for at least one or two more weeks, but there is so much going on with people talking about R3 forks and (rightly) saying something should be done... I feel like people should know that a few Rebol champions are doing their best to become team players :-)
other than that, sounds promissing ....
all that will be revealed in due time but consider the current major players like atronix involved. Not all members want their names to be public.
That's very welcome news!
On AGG, I think it is a great piece of code and I'm not sure Cairo is able to do all AGG can do. I don't see a need for a change to Cairo for now.
AGG seems much faster than Cairo to me. though Cairo has been maintained for longer, so it may have new features not available in AGG