World: r3wp

Gabriele, I understand you. Mov might be technologically even superior. 
So I don't know if it is licencsing of Apple or ignorance of Windows 
probrammers, but - I just want to use one codeck pack - ffdshow for 
e.g. It is some 5 years I met some video, which was not able to work 
with it. Any player! But - quicktime is painfull exception! I don't 
want quicktime player! I want it to play with any player I choose. 
And it does not seem being so. So, I have also VNC, just to have 
such problems as getting sound, but not picture, etc. So - no mov 
for me.

I agree that quicktime for windows does not at all show a fair picture 
of what quicktime is capable of.

Petr, I hated QT on windows too (or Itunes etc.). And, I hate the 
fact that MOV are often very hard to handle with open source software 
(eg. the DV videos produced by iMovie could not be processed on linux, 
but this was a couple years ago). But, I don't think it's the format 
at fault here. mplayer for eg. can easily play any MOV (as well as 
FLV, AVI, MKV, etc.), and VLC too, and they are both open source, 
so in principle there are no obstacles.

I'd rather see MKV or OGM being more used though, since they seem 
to be much more flexible (never looked inside though, so maybe they 
are crap ;)

So it would seem that we're almost back in business after some time 
in the quiet. Carl has been talking about vast simplification of 
how people can do networking. A bit in the same way as when you send 
data with a webbrowser from a form, you don't mess around with ports, 
but simple HTML code to do that. There will be more information about 
this later.

Cool.

Hello Carl and VID3 dev team i'm wondering something. I recently 
read alot on rebol3  lot of things are hsarper (VID3  is  really 
more performant with drawing statements for example). But as much 
i read so far I didn't found information about several topics.

What are the memory management enhancement proposed ? We all saw 
how it was difficulte to manage the mémory in previous rebol. For 
small data content that not a big issue but as soon you start to 
play with grafical content the mémory stack is amazing ( for example 
this code http://shadwolf.free.fr/berlinClock.ziptakes 10Mo  when 
running and in my opinion that from far 9M mega wasted ...). Can 
it be a way to make the recycle function more efficient to trap all 
non in use data

preset in the memory stack

next thing is the VID2 event system in same code we can see the rate 
face feel function don't allow the  event handling for the other 
face the Quit button for example.  (still in same code). Those things 
are trivial and i don't imagine to have to search hours and hours 
a way to solve them.

last thing is the "extension" modules  I would like to know how  
it's planned to handle them  when u add an external DLL to rebol 
VM your goal is not to have to rewrite a brigde code for each of 
your DLL you want to work with and you don't want too your rebol 
application code to be over complexified in regard to the regular 
rebol code wich use shaped  dialects. I know that's not easy thing 
to do ....

I want to be able to use any DLL in a rebolist way  to resume that's 
maybe an utopy but dreams allows

made the humanity advance  ^^

VLC is handling MPEG2  too and hum it's patented and hum lets say 
the authors hum .... how to say ..... hum .... well they just don't 
care

I believe efficient memory use is going to be a major focus.

There's no reason that the authors of VLC should care about software 
patents, shadwolf: Where they live (France), software patents are 
illegal and can be ignored. Go France!

Memory management: R2 gets a bad rap for this because Windows doesn't 
report the working set seperately, so the numbers it reports are 
a little inflated with page file memory. Nonetheless, R3 should be 
better with memory.

The extension modules spec (as you call it) hasn't been specified, 
or even discussed at length yet. That's next.

I think the graphics engine is much more memory efficient in R3. 
A single GOB takes up 64 bytes of memory where a FACE in R2 takes 
up much more memory.

Making sure to minimize extra references to data will make them more 
collectable too. The change in function contexts helps with that.

but of course we don't know what is happening with Vid3.4 yet

this gives greater performance scaling: R3 can easily handle thousands 
of GOBs, while R2 may suffer performance wise when handling hundreds.

of course a face and a GOB is not directly comparable, but just run 
the 1000cows.r demo to see the difference :-)

VID is at a higher level than gobs, but Graham has a good point. 
All we know is that it will be good code, because Carl is doing it 
:)

well, hopefully it will have actual features this time. :-)

although I'm not really that worried. if VID3.4 will be very different 
and inferior to VID3, it's important to have Gabriele finishing VID3 
to have a viable alternative as soon as possible for proper GUI development.

Why would Gabriele finish it for ?

if VID3.4 does not live up to our requirements of completeness and 
scalability. basically all the things that are currently wrong with 
VID, then VID3 will be the way forward.

I just don't see that there are enough users to support two VIDs

I agree, which makes it essential that VID3.4 is good enough. Perhaps 
it would help pushing Carl to make VID3.4 as complete as possible, 
so we won't need VID3.

there are usually only alternatives to something if the things already 
in place are inadequate.

Well, I don't see how Carl will have time to write all the widgets

So, I guess we all have to pitch in as soon as the prototype appears

He doesn't have to write the widgets. He only has to build an engine 
that will let you write most widgets with ease.

Yes, that was what I was meaning.

For example in VID it's very hard to build a well-functioning popup 
menu due to some restrictions on panels, clipping your content and 
you can't put things outside the window. in VID3.4 it should be simple 
to make a popup.

We need access to all the information that we can get to place those 
popups in the most appropriate area

we need to be able to replace Rebol native fields with OS type fields 
too eg. handwriting recognition

I had proposed a system to abstract input from the GUI a while ago, 
but it was mostly ignored. it's probably not that easy to implement.

Suggesting the impossible?  Or improbable ?

I don't know :-)

but what it would do, would be to let you use very different devices 
for regular input, such as a Wii controller. there would be no changes 
to the UI itself. if you need additional graphical controls like 
an on screen keyboard, it would be part of the abstraction rather 
than a part of your GUI.

then you make an input model, which maps controller behavior to what 
you want to get out, and then you could use it for regular input. 
this would work the same for input devices that some handicapped 
people use.

Have you done some work on this ?

only theoretical.

Or, is it just a gleam in your eye?

it's just an idea

but I think it makes sense. I've studied the problem a bit. Everyone 
else makes special cases out of it, rather than a generic system 
for strange input devices. I had hoped that VID3 could be the first 
GUI ever to do this. It would mean that you can write a GUI and a 
handicapped person or a person using handwriting recognition would 
be able to use it without modifications.

There was the Tao which scaled output to fit the devices available.

So, the reverse?