[REBOL] Re: Question: [ searching for answer on GUI speed ]
From: g:santilli:tiscalinet:it at: 13-Mar-2002 10:38
Hi Sunanda,
On Tuesday, March 12, 2002, 11:57:20 AM, you wrote:
Sac> different approach, or maybe not Rebol at all. I'm just disappointed that
Sac> Rebol/View doesn't render fast enough for what I consider to be a
Sac> small/medium application.
Actually, you should say "doesn't interpret the VID code fast
enough...". :) If you look into the source of LAYOUT, you'll find
it's doing quite a lot of things. It isn't using PARSE either, so
all parsing is done in REBOL, not natively. (This is to make some
of VID features work; I think LAYOUT could be improved anyway.)
Sac> Return
Sac> pad 40x0
Sac> Toggle 15x15 "-" "+" false
Sac> user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"]
Sac> [EsinTree/Toggle face/user-data/3 "Cseb-Tree"]
Sac> ESINTREE-TEMPITEM: text Blue bold font-size 14
Sac> "Text description of node"
Sac> edge copy []
Sac> user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"]
Sac> [esinCseb/LC-Tree-face face]
Sac> do (Append ESINTREE-TEMP ESINTREE-TEMPITEM)
What about:
Style tgl Toggle 15x15 "-" "+" false
Style nde Text blue bold font-size 14
; ...
Return
Pad 40x0
tgl user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"]
[EsinTree/Toggle face/user-data/3 "Cseb-Tree"]
ESINTREE-TEMPITEM: nde "Text description of node"
edge copy [] ; why? the copy should not be needed either
user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"]
[esinCseb/LC-Tree-face face]
Do [Append ESINTREE-TEMP ESINTREE-TEMPITEM]
; I think you were evaluating ESINTREE-TEMP here...
This might save a little bit of time.
Sac> My basic application problem is that I re-Layout the whole tree every time
Sac> there is a change to it. Maybe (typing aloud here) for _some_ changes, I
Sac> could update all the individual VID faces -- that'd be messy, but it would
Sac> mean the faces "above" the change are unaffected.
You should try two approaches:
- face iteration. I'm not saying it is easier but it could be
faster, and surely takes a lot less memory.
- directly manipulating faces, and maybe using the draw effect to
reduce the number of faces (you've got only two per row anyway,
so it's not a big deal). It is easier than you'd expect, and
will be much faster (in particular for operations that only
require moving faces, which will use hardware acceleration).
Sac> 3. My application implements a "persistant user state". So if the user is
Sac> positioned at the end of the tree view when they exit, that's exactly where
Sac> they are when they start it up again. Any rendering-on-the-fly code could not
Sac> (in this instance) assume the application always starts up at the top of the
Sac> tree -- so incremental rendering can't always be on a scroll-down, or
Sac> window-enlarge action.
You could relayout the code as you do now at the start.
My €0.02, ;^)
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
