World: r4wp

With HRD comes higher performant GPUs but I'm not sure how CPU scales. 
Look at Adobe, they are almost dropping support for classic display 
list (rendered on CPU) and forcing everybody to use their Stage3D 
which uses GPU. It's not easy move as there is almost no tooling 
yet, but it's a must. CPU is not able to process so many pixels with 
the new screens (with high frame rate). I don't say we should drop 
AGG support, just that there must come GPU support using OpenGL/DirectX 
and let the AGG to do high quality rendering of assets.

How to building using MinGW: https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw

Actually, Oldes, that's a great idea!  R3's new GUI could be built 
to utilize OpenGL by default.  That way, the GPU would handle all 
the graphics calls, and R3 would have 3D capabilities built-in as 
a bonus!  This would probably even make porting to Android and other 
platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?

It is. OpenGL ES2.0. As well as Android. Actually I don't think there 
is a chance to do GUI on these platforms without OpenGL.

We did a short test some time ago to use OpenGL, works but is quite 
some work to implement it completely.

The problem of OpenGL is it is great for rendering bitmaps etc. that 
can be used in 'crossplatform' way and I'd like to make such frontend 
for R3.... But if you want to implement something like DRAW  in OpenGLyou 
are getting into troubles. To do it properly you would need to use 
GL shader fragments.

When it comes to shaders, that means my 8 years old notebook won't 
be able to render it :-)

Also note that on Android for example the Canvas class (which is 
comparable to DRAW) is still not HW accelerated AFAIK.

I guess same is on iOS....the "draw' api is also not using GPU

The HW acceleration is still currently mostly used only for moving 
textured bitmaps...kind of fast blitter in the 2d graphics area.

Ofcourse if you want to create classical 3d game from textured polygons, 
shaders etc. that's the area where OpenGL excells (and the developement 
was mainly focused)

But good news is some people are experimenting with shaders to created 
2d oriented engines but until the main players on the market won't 
set some standard it can still take lot of time.

MaxV, I made a couple tiny edits to clarify https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw
.  I hope that's ok.

Couldn't DRAW work the same way as it does now, but render to a bitmap? 
 Then that bitmap could be rendered by OpenGL like it does any other 
bitmaps.

Yes, that's actually the method I'd like to upgrade the View engine...but 
not only for DRAW. The code would be modular so you can render to 
textures using any other library if you want.

I believe the Android porting effort will show us what is the optimal 
solution. It is good to find a balance between highly optimized but 
not much compatible HW engine and smoething that is fast enough and 
can be ported without big pain.

Just think, though, if OpenGL was the default renderer for graphics 
in R3, you could create a flat surface for a 2D screen, but during 
the same session, you could create another flat surface for another 
2D screen at a 90% Z-axis orientation to the first, and then rotate 
from the first 2D screen to the next 2D screen in a fluid 3D way.

I did quite a few tests with OpenGL on R2, but the killer for me 
was the inherent delay with R2 calling the methods (functions) in 
the OpenGL dll.  I was still able to rotate an object created with 
over 1000 coordinate points 30 times per second on a quad-core computer, 
but that's probably 1000 times slower than you could do it with straight 
C on the same computer.

I toyed with the idea of writing a C-based dll that could take all 
the information for rendering an entire data structure from R2 so 
R2 would only have to make one method call to a dll per frame instead 
of thousands, but couldn't get enough higher priority items off my 
list to get started on it.

I don't say you should use OpenGL for DRAW. There is no drawing api 
in Stage3D as well. I was proposing to use AGG to draw to bitmap 
with the best possible quality and let the HW do what it's made for.. 
to move pixels around. Bo understands it. That's actually how are 
modern apps made to have 60fps. To make animations just in AGG will 
not work (and honestly never worked). But maybe I'm too involved 
in animations and for many people would be enough to have static 
content. But that is not for future.

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.

https://developers.google.com/native-client/

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

That's good to know.  I know that Carl was aware of the browser limitation 
if not multi-threaded.  I just didn't know if he worked that into 
R3.

There's unfinished multitasking functionality in R3. It couldn't 
work if it would be impossible to use R3's internals in a thread-safe 
way. Indeed, the way functions work was redesigned to make it so

Has anyone tried to compile in 64bit mode and dived into the problematic 
areas already?

I think the first thing to look at is the structu sizes. Either press 
it back to fit 32bit size, or expand it into 64bit space. Not sure 
what kind of side-effect this will have.

Hi, I'm reading the REBOL3's source codes, and I don't know It's 
a typo or not: in this file https://github.com/rebol/r3/blob/master/src/include/reb-c.h
at line 61, about defining the uint type, It seems #ifdef DEF_UINT 
 was not correct. Maybe #ifndef DEF_UINT ?

LiH: to me it looks you are right, you can do "pull request" with 
the fix.

As I'm updating my old scripts on rebol.org, I'm trying to understand 
the problems with compress/gzip & decompress/gzip , 
and found at least one issue in u-zlib.c . 

When compressing, as the checksum method is assumed to be adler32 
for most of the code, stream->adler (the current checksum) is wrongly 
initialized to 1 in two places, giving an off-by-one checksum in 
the output and making it unusable for decompress/gzip. 

Still no clue for what yields the 
     ** Script error: value out of range: none
error and why calling 
     compress "" 

seems to fix this problem sometimes.It seems that something isn't 
correctly resetted between calls.

https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw

Now digit the following commands in MinGW console: => Now type ??

Can rebol be built to include .r scripts for a portable rebol?