AltME groups: search

switching the search to "opengl" brought this up near the top: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlDHPC

I'm using this feature in the OpenGL API, I'm working at. Maybe I 
could do a late reduce, when accessing the inner blocks.

I already have some OpenGL examples from the red book of OpenGL running 
in REBOL syntax. It's funny to see those examples in REBOL with the 
minor syntax. :-) I have no real idea of performance yet, I need 
heavier examples for that.

james, no C syntax. I'm making a REBOL version of the OpenGL API 
with REBOL syntax. Users will be able to use normal REBOL and call 
OpenGL functions (with REBOL syntax).

John, Is your opengl api rendering in a rebol window or face?

The commands are sent to a C program (task), that'll execute the 
OpenGL code. So the C program owns the window, not REBOL.

james, no. It's from 2 different programs. The datastructure is just 
used in one example. Some OpenGL commands take pointers to datastructures 
as a parameter.

You can see the full example here: http://home.tiscali.dk/john.niclasen/OpenGL/GLClient.html

First you have the C source, and below that the REBOL source, that'll 
do the same thing. I first thought about putting a REDUCE in, where 
vdata is defined, but I've changed my mind. The glVertex3fv function 
has to reduce it's argument.

Yes, it should be possible to call my OpenGL functions from an engine 
like that. That's the sort of things, I'm going to use this for. 
Only thing is, that the OpenGL window is inside a C execute, so you 
can't put REBOL controls (view stuff) in there. But you can then 
just have 2 windows.

One window with OpenGL output and another window with REBOL buttons 
etc. to control the thing.

How widely spread is it? Compiler for OS X, handhelds, alternative 
OSs? Does it speak with OpenGL and GLUT? What support of sound?

but i need to build the software first, and right now.. that depends 
(again) on R3... I will be using OpenGL to build the output image 
setups, then dumping the info to a monstrous image magic process, 
which in the end might actually process more raw image data than 
my HD actually can contain.  I expect render times in number of days. 
 (4 pictures on a much smaller canvas took more than an hour).

not sure. HeartBeat might be TCP related. On my Core 2 duo I am not 
observing jitter, just not smooth animation. Now remember that Amiga 
with 7MHz CPU was able to provide us with absolutly smooth scrolling. 
But Win32API lacks vertical blanking period synchronisation, so I 
wonder if without DirectX or OpenGL we are able to actually make 
our situation better ...

Yeah, looks good - do you have any guess how this would compare with 
Algodoo (speed-wise) once you're done? It does use OpenGL, but I 
guess you could too.

http://www.algodoo.com/

I would also like to build my OpenGL extension, now that I have everthing 
required in the extension API to start work on that.

yI'd look it up on MSDN there might be extra steps to update the 
transparency in real-time  but it is definitely doable, I've seen 
an animated opengl demo rendering directly over all windows without 
a window of its own.

my goal is to get the host code and OpenGL headers past the parsing 
phase.  once that is done, I'll start work on adding the production 
phase.


I still have to write the pre-processor, but that in fact is pretty 
straight forward.  there are little rules and they are much more 
static and well defined on the MS web site.

Maxim, the OpenGL situation in DirectFB is still quite unclear

DirectFB 2, with OpenGL support, still seems to be just a plan

There's an old OpenGL extension that was revived a year ago and then 
again not updated. If it works, it probably only supports hardware 
acceleration on one old video chip

So it looks like for some time to come, you will still need X11 for 
hardware accelerated OpenGL

Software OpenGL should be possible on SDL, though, for testing or 
low speed requirements

hardware rendering --- it has OpenGL, FrameBuffer and some other 
no-X ways... i don't know

I mean no-X OpenGL and no-X Framebuffer. Maybe that diagram is misleading 
but maybe it is not misleading

One of the details I left out in the above overview is how clients 
actually render under wayland. By removing the X server from the 
picture we also removed the mechanism by which X clients typically 
render. But there's another mechanism that we're already using with 
DRI2 under X: direct rendering. With direct rendering, the client 
and the server share a video memory buffer. The client links to a 
rendering library such as OpenGL that knows how to program the hardware 
and renders directly into the buffer. The compositor in turn can 
take the buffer and use it as a texture when it composites the desktop. 
After the initial setup, the client only needs to tell the compositor 
which buffer to use and when and where it has rendered new content 
into it.


This leaves an application with two ways to update its window contents:


   1. Render the new content into a new buffer and tell the compositor 
   to use that instead of the old buffer. The application can allocate 
   a new buffer every time it needs to update the window contents or 
   it can keep two (or more) buffers around and cycle between them. 
   The buffer management is entirely under application control.

   2. Render the new content into the buffer that it previously told 
   the compositor to to use. While it's possible to just render directly 
   into the buffer shared with the compositor, this might race with 
   the compositor. What can happen is that repainting the window contents 
   could be interrupted by the compositor repainting the desktop. If 
   the application gets interrupted just after clearing the window but 
   before rendering the contents, the compositor will texture from a 
   blank buffer. The result is that the application window will flicker 
   between a blank window or half-rendered content. The traditional 
   way to avoid this is to render the new content into a back buffer 
   and then copy from there into the compositor surface. The back buffer 
   can be allocated on the fly and just big enough to hold the new content, 
   or the application can keep a buffer around. Again, this is under 
   application control.


In either case, the application must tell the compositor which area 
of the surface holds new contents. When the application renders directly 
the to shared buffer, the compositor needs to be noticed that there 
is new content. But also when exchanging buffers, the compositor 
doesn't assume anything changed, and needs a request from the application 
before it will repaint the desktop. The idea that even if an application 
passes a new buffer to the compositor, only a small part of the buffer 
may be different, like a blinking cursor or a spinner.

In computing, the Direct Rendering Infrastructure (DRI) is an interface 
and a free software implementation used in the X Window System to 
securely allow user applications to access the video hardware without 
requiring data to be passed through the X server. Its primary application 
is to provide hardware acceleration of the Mesa implementation of 
OpenGL. It has also been adapted to provide OpenGL acceleration on 
a framebuffer console without an X Server running.

 http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure_(DRI)

As far as I know, DRI requires 3D support. DirectFB supports 2D hardware 
and drivers. It can be combined with OpenGL

It's quite possible that the OpenGL combination requires DRI

although OpenGL plugin would simplify that a thousandfold

yeah .... events applyed directly on draw elements or draw able to 
"map" and show directly other graphical organised video layers who 
be so awsome that way from example what is rendered on sub engine 
external like opengl one could then be applyed to a regular vid area 

In one hand you will have an easy way to interface events and on 
the other hand you can map rendering any kind of sub rendering

maxim already said that  about linking external grphical library 
result using image! data type

Maxim
20-Aug
[10...12]	

when Carl adds a few little image! enhancements to the extension 

API, I should be able to use a rebol image! as the interface to get 

the OpenGL render into rebol, using R3 view.  If memcopy works, then 
it should be VERY fast ( a few hundred images/second AFAICT)


yes Geomol did, but the limitations of R2 can't make it native... 

meaning, you don't have access to the binary part of the data and 
use it directly within normal datatypes.

the goal is to have an OpenGL gob :-)

yes as you say... an 3D gob using external render should be doable, 
either OpenGL or other engine.

yeah or drawing non image based texts ... most of the time in game 
text are all fuzzy small et because of the distance with using AGG 
to draw the text on top of your opengl embeded to VID layer you could 
at no cost  get a stable way to display them

don't know really.  but in any case, you don't have to use the library 
to do the rendering...  We can always render them using AGG or OpenGL. 
 as long as we have the coordinates.

AGG without a dialect? Might as well code in assembly, or openGL

We'll have some decent openGl implementation... right? :)

Champlain is much more complete and generic, except maybe the GPS 
track functionality. However, it uses Clutter, so OpenGL, so that 
must be available on your target platform

I don't know where to post this request, so I put it here:

I am translating some .h files of useful shared library to rebol 
( fmod,sdl,opengl) so if you know of a useful-multiplatform-publi-shared 
library

please give me lonks to binaries, .h files and test programs, thanks.

a tool which scans entire repositories of C/C++ code and builds bindings 
for various interpreted language... its one of the reasons python 
gets everything first... its totally integrated into SWIG... for 
example, SWIG was used to build the python OpenGL binding.  its just 
a question of getting the .h or the sources.  and then saying... 
I want to use it in [select language].

I guess you would build extensions per DLL. one for openGL, one for 
SQLite, one for audio, etc. no crisscrossing?

exactly... in fact, OpenGL provides the .lib files directly, so you 
in fact compile your own OpenGL DLL directly... no need to double 
reference the DLL  :-)

Taken from OS News (credit: Kroc Camen):


Google's Native Client (NaCl) is a browser technology to deliver 
native x86 binaries to users on Windows, Mac and Linux. Whilst this 
bridges the gap between modern JavaScript speeds and native binaries, 
portability is limited and that's especially important on the web 
where there's greater device diversity than on the desktop. Google 
are announcing that NaCl now also supports x86-64 and ARM. In addition 
to this Google are also announcing the ANGLE project, an open source 
compatibility layer to map WebGL (OpenGL ES for the web) to DirectX 
calls for Windows systems without an OpenGL library.


http://www.osnews.com/story/23021/Native_Client_Portability_Almost_Native_Graphics_Layer_Engine

Finally - http://developer.nvidia.com/content/accelerated-path-rendering-opengl-nvidia-path-rendering-sdk

so for elixir, I am thinking of building an OpenGL interface AND 
an AGG view based one using the same software. in fact, we could 
even have two simultaneous symmetric windows running and 0% code 
to add in the software :-)

(one in AGG and one in OpenGL, to compare them)

It would be nice if RT communicated to us in here, we who are very 
interested in working as closely as possible with RT, but cannot 
do work directly on the core, on what it would be a very good idea 
for us to consider building.


Like: "RT thinks you should look at building a GUI system" or "RT 
would like you to build a test case suite for R3" or "RT would like 
you to work on making OpenGL work well with REBOL as a dialect like 
VID" or "RT would love to see you building protocols for this and 
that kind of communication" or "RT needs a very good multithreaded 
webserver, that can handle X users" and have those efforts officially 
endorsed by RT, similarly to how MUI eventually became the GUI of 
choice on the Amiga to build your applications on. Perhaps put out 
hard specs and see if anyone will pick it up.


Right now, many efforts feel like they are there, not because RT 
felt they were a good idea, but because some individuals thought 
they were good ideas. Most of us here speak highly of our own ideas, 
but without much dialog with RT. AltME feels like it's the only non-RT 
effort that is endorsed by RT and perhaps also Cheyenne. Such directions 
would also mean that perhaps a lot of people would flock to the same 
official project, rather than starting 2-3 separate projects.

allowing me to use a gui and open it up in OpenGL, activeX, if I 
have the need/resources/time to provide it.  I mean to be able to 
extend the whole engine so I can skin it without needing to rebuild 
100% of the gadgets, etc... many of the things we spoke at the devcon, 
but more too.

Geomol, OpenGL, DirectX.... maybe? :-)

Skip DirectX, use OpenGL and implement it using GLUT. It works the 
same on all platforms.

Geomol, but I agree for the first round, OpenGL is more important.

Afaik, OpenGL is on Windows. I'm not sure, if GLUT is or it is linked 
with app.

About OpenGL: On this Windows 2000 machine, I have access to, I see 
"OPENGL32.DLL" and "glu32.dll" under /c/winnt/system32/

Geomol why do you think that opengl access should be done with GLUT?

so is OpenGL, I just do not understand why we should need some wrapper

GLUT is just some extra functions, that have same kind of interface 
as OpenGL OpenGL is just only basic graphics, where GLU and GLUT 
add things, that is used in e.g. games ... or in REBOL.

not very nice description of GLUT's internal state - http://en.wikipedia.org/wiki/OpenGL_Utility_Toolkit

SDL is more generally available than GLUT, and you can put OpenGL 
on top of it

AFAIK GLUT is simple wrapper which has been used mainly just to show 
some basic OpenGL demos. I'm not sure if this is a good  for usage 
in some 'real' crossplatform apps.

Regarding the OpenGL version of Rebol: this version is not yet worked 
on but I plan to work on it once the AGG based version is complete 
(as it this will give us much better big picture where the OpenGL 
advantages could be really useful in the visual system).

AFAIK the plug-in interface is not yet finalized so it is too early 
to discuss ho this will be exactly exposed.


But there are more things to consider than the blitting. If you do 
SW redered graphics you need to render into the  backbuffer in the 
main memory then you transfer block(s) sing a blit to the gfx card. 
If you do HW accelerated graphics you need to transfer all bitmaps 
into the gfx card memory first..also you are limited by the OpenGL 
2D functionality (which is not so flexible and pixel perfect as for 
example AGG implemntation). Also setting pixels directly in gfx card 
memory is possible but this is surprisingly the slowest way to dorendering! 
Why? Because fur current PC HW bus architecture is such transfer 
very expensive operation comparing to moving one big block of data.

So as you can see all this (and lot of other issues) needs to be 
considered not to mention that the solution should be as much as 
compatible on most of platforms.

Once the beta is released it will give us good picture how to make 
the gfx system even more optimized and extensible.

there used to be a running joke in my workplace that whatever startup 
company i got excited about was doomed to failure.  Be Inc. with 
BeOS (focus shift), Constellation 3D with their Flourescent Multilayer 
Disks (FMD) (factory bombed in start of Palestinian intifada), and 
now Rebol?


Each of the technologies was/is paradigm shifting in their field 
but through mismanagement, mishaps and miscommunication something 
along the way seems to get lost and the excitement they originally 
engendered fades from the public eye. 


If, in the case of Rebol3, it simply is too much work for one person 
- then perhaps now would be the time to open such areas as View development 
(the underlying system) and advertise to the 'World' "Come, see what 
you can do!".


Personally, I'd love to see Cyphre's work with View taken that one 
step further and translated into OpenGL and all that entails.  Not 
everyone today is looking to use Rebol only on their embedded devices 
;)

AGG/Draw in R3 is very powerful - but view limitations (transparent 
surfaces etc) seem to hold it back.  Again - rendering to an OpenGL 
surface might solve some of these issues?

It would be nice to get a 20 - 50x speedup from OpenGL :)

I think Opengl Is alliased T___T and unstable on unix/ linux (basicly 
because of the lack of ground constructor really optimised drivers 
and upto date ...)

OpenGL works great on Ubuntu for me

Opengl is too big for using 98% of the time 2D things

when you compare the size of OpenGL to win32 GDI.. you wont find 
a lot of size difference - only feature difference

Isn't OpenGl more comparable to DIRECTX?

I saw I project of a VM  based on OPENGL  for 3D interface it's name 
was IO  or something like that I stopped it as soon i downloaded 
it the helloworld was bigger in memory than in rebol

That's why X/OSX/Vista has been trying to centralize the OpenGL/DirectX 
rendering, to share the load.

the thing that OPenGL  is not rendering on screen anything It mainly 
offers matrix handling routines and GLUT does the rendering on screen 
...

i dont use GLUT with OpenGL - but rather call it direct - ive found 
GLUT is slow.

the other problem with rebol -> opengl is the data formating .... 
and all try to link opengl encounter that issue

R3 could hook into the display list feature of OpenGL for compositing

The browser as the launch platform for applications has always been 
an interesting idea. The fundamental problem of the sheer complexity 
of it can be solved with R3. If done right, it can completely wipe 
the floor with browsers and AJAX. I think the problem is that we 
haven't been speaking in a language that people can understand, such 
as "browser", "web2.0" and "webserver", but instead "dialects", "VID", 
"Viewtop" and "X Internet" and people go "huh?".

Some things I believe are needed to do this right:


- Browser form factor. People are used to browsers, not Viewtops. 
What's always the first thing a complete newbie computer user uses, 
when wanting to do anything on the internet? A webbrowser. I don't 
want a desktop inside my desktop. There are tens of solutions for 
such things and they are almost all forgotten. Carl is doing the 
REBOL browser. When you fire up R3, you will get what looks like 
a webbrowser and acts like one. The concept has to work equally well 
for people like us, as well as 5-year-olds and 95-year-olds.


- Do apps that are similar to webapps, like GMail. That's a quick 
way to compare. Don't you think a 50k GMail look-a-like inside a 
REBOL browser running at native speeds would be _slightly_ impressive? 
Remember to say that you can serve 5 times more users with the same 
bandwidth. REBOL can help make raw numbers look better without much 
effort. Google would have to use it as a content platform. They have 
no other choice. :-) Chrome? What's that?


- Plugins suddenly are very flexible. You don't have plugins as in 
Firefox, but helper scripts that can enhance/change your browsing 
experience. 15k full screen document reader that prettifies plain 
text files? Sure thing. Blog posts presented in that would be much 
nicer to read. Out goes the PDF reader.


- Do apps that are completely out of the league of AJAX, such as 
multithreaded P2P systems. In fact, why not build P2P capabilities 
right in? Have different instances of the browser allow users to 
connect and chat, when they are visiting the same "Rebsite". It's 
sort of like going into a physical store and chatting with the other 
customers and you decide to exchange business cards. Initial contact 
without needing email. Do the same thing with chat support for an 
article that you bought at that  "rebsite". Current websites are 
almost completely anonymous. You don't feel you are entering a live 
community. Coded in REBOL/Services.


- Webpages are now REBOL scripts. In R3, scripts can be closed and 
encrypted, so you can't read the source and you can sell scripts 
and have them signed. The best you can do right now is some kind 
of code obfuscation.

- Windows, MacOSX and Linux version.


- "A webbrowser that directly supports OpenGL without obscure/limited 
3rd party plugins." Say that again in your head.


- It's very important that the public get to see that creating REBOL 
scripts for the browser is very similar to creating plain HTML pages. 
REBOL scripts can be served off a plain webserver. All the infrastructure 
is already there. Or how about serving scripts from the browser itself? 
AltME can both be a client and a server. It's that P2P thing again.

- Browser would run wherever R3 runs.


- Market it as Web 4.0. Market it as a direct competition to current 
webbrowsing.


- Browser would be a 500-600 kb downloadable exe that starts immediately 
without installation. From deciding to get it, to be using it to 
browse "Rebpages", it should not take more than 30-45 seconds.

- We need AltME in that browser (Altissimo?) as well as QTask.

For developers:


- It's easy to create an HTML file in notepad and display it in your 
favourite browser. It's going to be equally easy to create a REBOL 
script in notepad and see it running in your REBOL browser. A 5-year-old 
who has just learned to type, should be able to create a script and 
display it.

- One language for everything.


- Everything is free. You can start out with notepad. The barrier 
for creating content is about as low as it can get.


- You wanna code slow web 2.0 apps or fast web 4.0 apps? Hard choice, 
I know.

This is basically what I meant earlier about being "psyched about 
a REBOL browser". I left out things like video playback and advanced 
audio, because I don't know yet what the approach for making those 
things possible will be. But if they are possible, they would be 
equally possible, like OpenGL would be possible.


And if it turns out that he won't do the browser himself, then it 
can easily be a community effort, not hard to build.

Henrik: "When you fire up R3, you will get what looks like a webbrowser 
and acts like one." - not just that, I want R3 not just to look like 
a webbrowser and act like a webbroser but actually TO BE a webbrowser 
- download R3 (few hunderts kB), run it and be able to browse REBOL 
pages - and if you enter *.html - just show some window that says 
"downloading" and download some REBOL plugin that can display webpages 
(being based on Gecko, Webkit, whatever) - it will be few megs download, 
but people are used to it. This is definitely possible - it's possible 
to display OpenGL etc in View window so I believe there are some 
libraries to do this ("somebody" just needs to make an interface 
to them ;)'


The thing is that R3 browser (and just a R3 browser) will be once 
again a great platform without apps (Be Inc etc...). If R3 browser 
can display classic HTML+JS+CSS+DOM+XML+AJAX+WHATEVER combo it's 
win-win situation. Lots of apps available and we can improve them 
one after one to show it can be done much easier and faster.

not ready yet, but just wanting to see where things are now, so I 
can place my time and efforts properly.   Already started to look 
at OpenGL a bit and started doing C++ again.

at sound (to my limited knowledge) there are many solutions but neither 
one is ideal. It's not like software rendering for graphics - where 
you know they will work everywhere. Or even OpenGL (which has problems 
on certain % of windows users because of bad drivers)... there is 
OpenAL but it also won't work on some hardware. Example of this is 
that something as big as Java doesn't have a solid sound library 
that would work in non-signed applets. I wrote a game in processing(java 
lib/lang) but had to rewrite it to java+lwjgl+jopenAL because there 
was no way to make native java play sound consistenty. Basically 
it didn't work on more computers that it did, and processing is very 
media oriented.

( + if I will need gui for desktop server, rebol has lighweight software 
rendered gui, factor also has a gui but on windows it's opengl based 
which is not really practical for a gui.. even casual games on windows 
try to use DX7 renderer for maximum compatibitily and avoid opengl 
beacause of driver issues)

Factor has very reactive/alive comunity... they make bindings to 
a lot of stuff quickly thats why I prefer it.. they have everything 
from web-server/web framework to opengl stuff, etc

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Another reason im interested in AGG richtext (as opposed to text 
gobs) is that i'm intending to use OpenGL rather than rebol rendering 
once the plugin architecture is finalised.

ex  integrating DirectX/OpenGL into view... nope.  loading dll classes... 
nope... etc, etc, etc.

now if we can be the go-between things like these libs and opengl 
.....   :-D  can you see where I'm going ?  we already have a dataflow 
engine which could act as the kernel for managing when updates need 
to occur, and all rebol is doing is the whiping, while the grunt 
work is done by the various libs out there  ...

focus changed to plugins AFAIK, since that will allow Other people 
to start working on tools for REBOL 3 while Carl addresses the core 
stuff.  

I, for one, will start porting OpenGL natively to REBOL, once the 
plugin architecture is functional.

Haven't used R3 for anything serious yet.


but now that extensions are upon us, the OpenGL integration will 
allow me to use R3 for a *VERY* serious project.  still need Carl 
to fix the make/copy issue before I can convert most of my cool stuff 
over to R3 (like liquid and globs).

I hope extensions will be in the linux and mac ports shortly.

OpenGL integration is a too big project for me, i lost my motivation 
after some days

Its working on my system  :-)


when A80 is out, depending on what he will have added to the API, 
I will try to port a simple OpenGL game to REBOL  :-)

on my part, once Carl adds either one or both of my requirements 
for the next evolution of extensions, then I can proceed with a fully 
independent version of a GUI written in OpenGL... no need for any 
internal view stuff a part from the image! datatype... not even window 
manager.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

it's easy to make a VID front end to pilot a oggvorbis player for 
example it's more difficult to mix VID and opengl.

actually it isn't hard to mix VID and OpenGL  :-)  all we need is 
a way to do a quick memcopy of the OpenGL pixel buffer into an image! 
datatype... that's it.  really simple.


now I dont want to be forced into using View though.  I want to be 
able to use extensions to control the windowing too.  I need to be 
able to use other window managers if I want to integrate into better 
engine which are already ported to all major platforms.  Things like 
open scene graph or other game-oriented 3D engine, DirectX, whatever.

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

pekr, once you see what can be done with a 3D engine you won't call 
it crap... believe me.  Apple's GUI is based on a 3D engine, which 
I believe is based on OpenGL... can't remember precisely.  same thing 
for vista's aero which is based on DirectX which also uses 3D.

If R3 has VID3 working, I'll probably use it for some projects... 
but when GLass will start to work (using OpenGL) then I'll probably 
never need VID anymore.  simply cause it'll do 5000 frames a second 
for my interfaces, including very advanced looks and next gen functionality 
like run-time interface manipulation by end-users.

sound support, video encoders,  DirectX, OpenGL whatever...

like cliping a video or a opengl/direct 3D rendered area to a vid 
box.

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

for my part, when R3 goes open, I'll be integrating liquid-paint 
with OpenGL asap... which will completely alleviate my need for /view. 
 we will have a 3D native GUI  :-)