World: r3wp

I was just curious, because even with new series unique is much faster.

faster, but not GC safe

its a shame that all "set" functions make new series.  we could just 
easily copy before calling unique:
new: unique copy serie

Agreed 100%

though there is a lot of memory overhead for large series, I'd rather 
have a refinement on all sets probably   /only  or something similar, 
to have them work "in-place"


come to think about it, maybe we could make a CC wish for this, seems 
like its been a topic of discussion for years, and pretty much eveyone 
agrees that both versions are usefull.

SWAP is another interesting one... takes two series and swaps their 
content, in-place.

I don't see your point with SWAP

INTERLEAVE is a very usefull function, using two series and mixing 
them up with many options like counts, skip, duplicates, all cooperating.

SWAP is interesting, though not as usefull... I don't remember when 
I used it.  ;-0

(that was supposed to be :-P)

anyway, I really think that we should accumulate all of the series 
functions we are using (even the more obscure ones) and make a big 
standard series handler module in R3.  it helps people who are learning 
REBOL since they don't have to figure out as much how to build these 
(somethimes non-obvious to implement) funcs.

this module could even be an internal delayed load extension... which 
can include some functions in C and others in REBOL mezz within the 
extension's module.

steeve, I think I was using SWAP for some sort of sorting using the 
/part refinement.

hehe I just discovered that SWAP is already part of R2 and R3   :-)

though its missing a few refinements to make it really usefull.

Steeve: "faster, but not GC safe" - in some nonstandard sense?

hum yeah, just to say, that lof of memory is allocated.

I know most of peoples don't bother.

I bother a lot  ;-)

But doing a sorting algorithm without any clue about memory alocations; 
is just ... clueless ;-)

well, I do now...

yeah GLASS has some leakages :-)

but not only GLASS, we have the same wory in any GUI engine

several tens of megabytes to just display a simple GUI pisses me 
off

its mostly that liquid caches a lot of things for data, so I'm now 
doing all I can for the processes to hit the GC less and less.
the reason is because it increases performance A LOT.

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.