But of course, it's not an easy task. One must be careful to make it right.. all the draw command batching, texture packing etc.
Oldes, I don't argue with you and Bo about that. I think we all know the state of this technology. I've already did several prototypes of such "engine" so I have some ideas how this could be done for R3 it's just matter of prioritizing&time&resources. I wrote about the drawing apis just so other people know OpenGL is not any Messiah if you want to do hi-quality 2d vector graphics in realtime. I'm not against HW acceleration at all. It's just not easy topic in this non-ideal programming world as you pointed out. I see the solution with good high quality rasterizer + HW accelerated compositing engine. That should be flexible setup at least IMHO. Plus this way also we got the classic 3d api for free.
Bo, I even tried to HW accelerate the AGG renderer code so it is completely using OpenGL...works well and you can use draw directly inside the OpenGL context mixed with 2d surfaces or 3d objects...lot of fun. But still , lot of stuff is still computed on CPU that way. Nevertheless its still better that fully SW based renderer.
The best solution for nowadays gfx HW would be to rewrite most of the AGG code for GPU using shaders. That would be state-of-the-art 2d engine for future. But also pretty big task ;)
What do you think is the best roadmap for the graphics engine in R3 right now? Simply port VID to R3 to start, and then in R3v2 change out the graphics engine with hardware-based code?
There are plenty of possibilities here. Either port VID and have to deal with it's flaws and the history with it or go the path of the RebGUI or redo VID I have read somewhere that Carl expected someone to come up with something better than VID. I like VID yet it has its oddities, like when positioning elements using 'at. It could be improved in some of its behaviours, if you import it you may be hindered by this aspect, and it may get harder than restarting with a restricted base set of widgets.
we are out of topic here probably
I don't think we're really out of topic here as the graphics stuff pertains to porting to different platforms, but if you wish, we could move this to the View/VID group.
When Carl was developing VID, he clearly expected that VID would not become the de-facto standard for Rebol graphics. The face engine was the de-facto standard, and VID was simply one of what he expected to be several dialects for the face engine. There were a few others, like GLASS, that came about.
Bo, I think if we don't make drastic changes to the GOB mechanism we should be safe when building anything on top of the GOB datatype. The gob! is in fact abstraction layer between the "VIew engine" and any "GUI framework" written in REBOL. So as take this example: We have now R3GUI framework which runs quite well on the current View engine (although this engine was build in 2 weeks during the very early R3 alpha work so it's kind of Q&D prototype ;)) (BTW should I mention the R3GUI is much better than R2 VID?) Anyway, the R3GUI works on current View engine. When I tried to change the engine so it uses OpenGL accelerated AGG the R3GUI still worked without any problem (except visual bugs caused by incomplete OpenGL code implementation of the new prototype). SO from that example you can see the "View engine" and "GUI framework" are two independent things and can be developed or even exchanged separately.
From the "design architecture" POV we should focus on stabilizing the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. If these layers are fine-tuned you have great base that allows us make experiments at the low-level graphics and also as well at the high-level GUI abstraction layer.
So to sum up my thoughts: -anyone can even now start working on it's own great GUI dialect for R3, or contribute and enhance to already existing R3GUI (latest version will be published soon) -anyone can create own great low-level graphic engine for XY platform or just one native binding for specific os -work of these people won't be useless if they stuck to the current gob! datatype
Ofcourse we can do slight changes to the gob!s or draw dialect as well but these should be always easy to incorporate in already existing code that relies on them
We made it to compile R3 into a single EXE. Filesize: 855566 can be packed with UPX down to 368654 (43.09%) That's the base we use for encapping R3 apps into a single EXE.
Cyphre, thanks for that info. So does the R3GUI framework work on all current R3 platforms? I understand Android is a no, but everything else?
Robert, do you have instructions posted anywhere for how you encap R3 apps into an EXE? I'd like to publish that somewhere.
Bo: R3GUI depends on the R3 View engine, which is currently only publicly available for Win32 (and that only as part of the former host kit releases, not yet integrated with the open source R3).
An Amiga port of R3/View reportedly also exists, but I don't know about its state.
The R3 I mentioned is R3-View. I'm going to publish it with the latest R3-GUI. Announcement will follow.
I wonder, if in today's web situation, it would make sense to reopent the browser plugin project?
Don't know what the effort to get something going would entail as a regular plugin, but maybe as a Chrome Native Client there could at least be something available for Chrome more easily. It seems less work, at first glance.
It would be interesting to port R2/R3 under Squeak/Pharo, http://squeak.org. Just an interesting thought.
I believe in order to do the browser port properly, the R3 engine would have to be multi-threaded or it would only work in one browser window. That seems like it would require a lot of rewriting if it isn't already in the design.
R3 is designed to be able to be thread safe. Whether it actually is that currently is a different matter