Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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: