World: r3wp

I know, it will better Max

the issue comes from the internal data model used by Rebol

In the next release of glass, in the TO DO file, I list a few measurse 
to increase performance and decrease ram use by concentrating on 
using as much persistent data than throw away recycling.  but that 
means a complete overhaul of liquid and glob (the rendering engine 
over liquid).

128 bit for a value slot is hurts a lot in some cases

yes.. that grows ram quickly.    but the biggest memory mongering 
in REBOL is the binding.

(by far)

liquid uses class, so its about 100-200 times less memory intensive 
than it would be otherwise.

and this can scale to 400 times faster when ram grows above 400MB 
(the GC is obviously exponentially slower)

I tried your demos with intensive recycles, but the only gain was 
3 MB among 30+ MB

I've done very little actual optimisation in liquid cause it works 
well and the lazyness is very efficient.  the lazyness actually helps 
a lot for GC because a lot of the data is never recomputed, its reused. 
 though because I'm only using one layer, the root frames end up 
composing the entire display a few times.

with 3 layers, I should bring that down a lot.  I'll also be rendering 
on a bitmap directly, enabling clipped region rendering, using only 
a widget's new drawing instead of the whole scene.

the rendering could be faster, but on contrary, more you use layers 
more you  should consume graphic memory

a layer = an object/gob

no, layers are just draw blocks.  each one applied at different optimised 
times.

?

Ok, if you use only one object/gob then the whole thing is rendered 
each time

each layer creates a tiny object for every widget, but the size of 
the draw blocks is immense, so it will save memory in the end.  if 
we have 10 objects storing  10000 items 10 times 

vs 10 storing parts of those 10000 objects 10 times the memory saving 
should be significant.

its like 10000 * 10 vs 100 * 10.   the bigger the scene, the bigger 
the savings.

and then I can just render 3 of those at a time, so instead of rendering 
10000 times I can just render 100... in rendering that will help 
too.

maxim, do you plan to add more widgets to glass?

Ok for the rebol side, but the graphic engine will have to render 
the whole scene each time. It could ne slow in some cases

Tom, I'm working on the most advanced text editing widget you've 
ever used right now.

great! important one. something linke treeview, ribbons etc.?

looks like esp. treeviews are quite difficult?

steeve, with layers, I split up the rendering into different things. 
  bg/fg/interactive.  and I don't have to render the bg all the time, 
only on resize. 

I'll also be able to render just a single widget directly on a bitmap, 
using AGG clipping to that widget.

I just realized where really in the wrong group ;-)

given that the default-extension in R3 is currently %.reb, are we 
actually supposed to use this?

or is it likely that this will be switched to %.r3 anytime soon?

(given that most people currently seem to use either %.r3 or %.r)

No, you're not really supposed to use .reb, you're supposed to change 
the setting to what you were going to use anyways.

That's why the setting is .reb: There is no consensus on what extension 
to use, so the setting is set to something noone uses.

See http://issue.cc/r3/1573for remove-duplicates and the reason 
it's not as good an idea as you might think. It turns out that the 
set functions have to allocate a new series to do their work (for 
series larger than trivial size), even if they were changed to modify 
in place. So you can't avoid the allocation; might as well benefit 
from it.

its a good idea, because I can't copy the series, its linked in many 
places.

Look a the proposal in that ticket. It works the same as yours but 
faster.

And it's order safe.

and if the function does this internally in C it will still be MUCH 
faster  which is why I'd much prefer having refinements for in-place 
functioning of all set functions.

yeah, that implementation is pretty neat.

using refinements also means less functions to remember... there 
are quite a few set functions.  I don't want to have each one duplicated 
as a mezz function.

It has to allocate another series anyways, as the set functions do 
hashing. In-place is just for convenience, not to save memory.

I know, but everything that's done in the C side will save on speed 
and memory, since the C doesn't have to go through the GC and all 
that.  in tight loops and real-time continual processing, these details 
make a big difference in overall smoothness of the app.

which is why its preferable to do it there anyways... and the fact 
that we only have one function name to remember for the two versions 
is also a big deal for simplicitie's sake.

I just realized that if Carl is using a hash table for some of the 
set functions... does this mean that its subject to the 24 bit hash 
problem we discovered in maps?

Yes, until that's fixed.

See also http://issue.cc/r3/1574

You could add /no-copy refinements to the set functions though. Of 
course this would switch which half of the set functions are misnamed 
:)

/no-copy would be really nice... its been a recurring discussion 
for years by many of us, which proves that its a required feature 
IMHO.

copy or not, there is no more "correct" version, they both are.

No, I mean that modifying functions should have verb names and non-modifying, 
not-for-effect functions shouldn't. So for the current set functions 
UNIQUE, DIFFERENCE and UNION have good names, but EXCLUDE should 
be called EXCLUDING and INTERSECT should be called INTERSECTING; 
this gets reversed for modifying versions :)

But that's just being silly, unless we're adding new functions that 
need names.

yeah.