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

Question: [ searching for answer on GUI speed ]

 [1/21] from: rebolinth::nodep::dds::nl at: 11-Mar-2002 23:16


Hello All, I have read somewhere that Rebol/view is completly written with the Rebol/core. And that Rebol was build for modern machines with process modern process power.And what amazes me is the speed of Rebol/view? For a simple Gui layout menu's the Rebol/view scores quite good on performance. But even the slightest extra in GUI mode bring my PC down to speeds of a XT machine, NO offence! Im using a P200 MMX, voodoo3 16 MB card. Rebol/View cant run on this machine smooth, impossible. But when I start the same application on my PIII 600 MHZ that application still is slow like burning sugar. (I know GUI is not an easy topic based on 40 different OS'es ;-) So Im wondering, Is the basis maybe not fast of Rebol/view? or is it that the core ontop of the OS is causing the delay on GUI output? Im a programmer from the old days, Put as many, in as little code as possible, and get the best effort out of the smallest code. Nowadays this does not count anymore for programmers. Rebol did a very good job on the speed of the /Core, but the /View part could be better im my eyes? Or am i day-dreaming :-) So for the small part Rebol wins here ;-) 220K (compressed) is creazy small for a programming language this format:-) But for the efficiency part on the Gui? I cant place it. Can someone clear me a little up about the inside on the /View part, the way of thinking behind the design of the GUI, because im wondering.. ..Maybe im wondering too much :-) Just a currious user searching for an honest answer ;-) Kind Regards, Norman.

 [2/21] from: greggirwin:mindspring at: 11-Mar-2002 16:38


Hi Norman, << For a simple Gui layout menu's the Rebol/view scores quite good on performance. But even the slightest extra in GUI mode bring my PC down to speeds of a XT machine, NO offence! >> Since I don't know what you're doing, it's hard to say where the slowdown might be occurring. If you apply a lot of effects to a lot of faces, or if you have a large face that you refresh often, it can slow things down quite a bit. Large faces seem to be the biggest hit I've seen in my stuff. I built a GUI app with multiple list boxes and some small pictures, which did lots of data manipulation and it was plenty responsive on current hardware. I'm running a P900 here and I think most machines we used were as fast, or just a little slower. Performance can vary widely, but just look at Cyphre's Arcadia game engine. I get 25 FPS in fixed size mode and ~11 FPS at ~900x700. --Gregg

 [3/21] from: sunandadh:aol at: 11-Mar-2002 19:31


Norman:
> For a simple Gui layout menu's the Rebol/view scores quite good > on performance. But even the slightest extra in GUI mode bring my > PC down to speeds of a XT machine, NO offence!
I tried to speed up an application I had written, and the one sticking point was Layout. The application creates a tree view from a hierarchical structure. Nothing fancy, each line is simply made up of: -- A Pad to indent. -- For nodes, a Box with a +/- and a left-click action facet. -- A Text line with a left-click action facet. -- If the branch is closed, a text That says how many elements are "hidden" Composing the block is almost instant. On a 1ghz Celeron (Win98), the Layout command alone takes about 1 second to process 200 lines. That's way too slow. I want to be able to handle 800 lines (at least) on a 400Mhz Pentium when (if) the application deploys. I could, of course, render only the bits that are visible, and write some interesting code to add faces as the user scrolls them into visibility, or opens and closes branches. Other parts of the application -- including things I thought would be a problem such as the recursive sorting of tree branches -- are often too fast to meter. Maybe this is in part because VID is really only release 1, and the magic optimisations are coming along real soon now. <dream>
>> Type? :Layout
= native! </dream> Sunanda

 [4/21] from: greggirwin:mindspring at: 11-Mar-2002 22:38


Hi Sunanda, << I tried to speed up an application I had written, and the one sticking point was Layout. The application creates a tree view from a hierarchical structure. Nothing fancy, each line is simply made up of: -- A Pad to indent. -- For nodes, a Box with a +/- and a left-click action facet. -- A Text line with a left-click action facet. -- If the branch is closed, a text That says how many elements are "hidden" ... I could, of course, render only the bits that are visible, and write some interesting code to add faces as the user scrolls them into visibility, or opens and closes branches. >> I think rendering only the visible parts is the only way to get things to scale up, GUI-wise. In your example, you're creating somewhere around 600 faces (if I understand that each of the 200 lines creates a Box, and 2 Text items). I have a few ideas sketched out for how I might tackle a grid or tree-view, but haven't made any stabs at implementations yet. The design path I'm heading down is centered around DRAW commands rather than individual faces. I have no idea, yet, what issues I'll run into though. --Gregg

 [5/21] from: carl:cybercraft at: 12-Mar-2002 23:30


On 12-Mar-02, Gregg Irwin wrote:
> I have a few ideas sketched out for how I might tackle a grid or > tree-view, but haven't made any stabs at implementations yet. The > design path I'm heading down is centered around DRAW commands rather > than individual faces. I have no idea, yet, what issues I'll run > into though.
Wouldn't using View's 'list be the way to go? It supports multiple faces per line. -- Carl Read

 [6/21] from: sunandadh:aol at: 12-Mar-2002 5:57


Gregg:
> I think rendering only the visible parts is the only way to get things to > scale up, GUI-wise. In your example, you're creating somewhere around 600 > faces (if I understand that each of the 200 lines creates a Box, and 2 Text > items).
You are absolutely right for large-scale applications. If I'd thought I'd needed a tree with thousands of open branches, I'd have started with a different approach, or maybe not Rebol at all. I'm just disappointed that Rebol/View doesn't render fast enough for what I consider to be a small/medium application. To be fair to View, since sending that last email, I've actually looked at what my code produces for a tree node (similar code for leaves), and it is a bit more complicated than I'd indicated -- the code also captures each text face in a block, and sets up user-data. Return pad 40x0 Toggle 15x15 "-" "+" false user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"] [EsinTree/Toggle face/user-data/3 "Cseb-Tree"] ESINTREE-TEMPITEM: text Blue bold font-size 14 "Text description of node" edge copy [] user-data ["S" "Z1S0000W" "Esin-Z1-Z1S0000W"] [esinCseb/LC-Tree-face face] do (Append ESINTREE-TEMP ESINTREE-TEMPITEM) Although commenting out the Do and removing the assign makes an almost unmeasurable difference to the speed. The speed problem is in Layout and (I guess) relates to its speed at rendering. My basic application problem is that I re-Layout the whole tree every time there is a change to it. Maybe (typing aloud here) for _some_ changes, I could update all the individual VID faces -- that'd be messy, but it would mean the faces "above" the change are unaffected.
> I have a few ideas sketched out for how I might tackle a grid or tree-view, > but haven't made any stabs at implementations yet. The design path I'm > heading down is centered around DRAW commands rather than individual faces. > I have no idea, yet, what issues I'll run into though.
It's good to know someone is working on it. The sort of generic issues I came across while developing my application-specific tree viewer (it would take a bit of work to make it generic are): 1. Any change to the internal state (opening/closing a node, deleting a node or leaf, sorting the leaves in a node, moving a node or leaf) require me to re-render the _whole_ tree. This is exactly the sort of issue you want to avoid. 2. The internal tree object and its matching VID layout need to be cross-indexed -- so you can go from an entry in the object to its face, and from a face to the tree object. I chose to do that by: a. Ensuring each tree object entry has a unique id (its path from the root) b. Putting that id in the face's user-data (giving me via a tree search, a way to go from a face to its corresponding tree object) c. Capturing the faces in Layout and (after Layout) putting each face object into a variable in its corresponding tree object. This means the tree objects have "direct access" to their corresponding face, but at a cost of having an unmoldable tree (I wrote a tree-print routine to get round this). 3. My application implements a "persistant user state". So if the user is positioned at the end of the tree view when they exit, that's exactly where they are when they start it up again. Any rendering-on-the-fly code could not (in this instance) assume the application always starts up at the top of the tree -- so incremental rendering can't always be on a scroll-down, or window-enlarge action. 4. My tree object turned out to be more complicated than I'd first envision. With a bit of code-rework, I could lose a couple the fields, but right now it looks like: TREE-OBJECT: make object! [TC-Type: copy "?" ; node type TC-TypeID: copy "?" ; Node type level TC-SortID: copy "" ; Branch sort order TC-ID: copy "?" ; ID for this item TC-ParentID: none ; Internal id of parent TC-ParentNode: none ; actual node of parent TC-Title: copy "" ; Title to display TC-Open?: true ; Is this branch displayed? TC-Hidden?: false ; Is this node and branch hidden? TC-DATS: copy [] ; VID display attributes TC-LeftClick: copy [] ; VID Left click action TC-RightClick: copy [] ; VID Right click action TC-Face: none ; Actual VID face (none if in a closed or hidden branch) TC-NodeID: copy "" ; ----: Internal use only. to give ; each node a unique id TC-Inner: copy [] ; Child tree objects ] I hope that helps a little with the "user requirements" Good luck!! Sunanda.

 [7/21] from: riusa:email:it at: 12-Mar-2002 13:32


Where can we find detailed information how to handle "list" object? I found only brief examples. Thanks a lot!
> On 12-Mar-02, Gregg Irwin wrote: > > I have a few ideas sketched out for how I might tackle a grid or
<<quoted lines omitted: 10>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
++++++++++++++++++++++++++++++++++++++++++++ Alessandro Manotti Presidente dell'Associazione "RIUSA" Sito web: http://riusa.apritisesamo.net email: [riusa--email--it] mailing-list: [riusa-ml--yahoogroups--com] Telefono: 347.63.43.231 -- Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f Sponsor: VolaSMS, il software pi=F9 completo per inviare e ricevere SMS dal tuo PC Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=276&d=12-3

 [8/21] from: gerardcote:sympatico:ca at: 12-Mar-2002 9:06


I just saw that I didn't enclose the ELICA web site http address for you to look at if you desire to do so. Here it is : http://www.elica.net/cgi-bin/eligen.exe?elica Just try to display the Map in dual mode : Graph and Text and see for yourself how it is done and how each reacts. Regards, Gerard

 [9/21] from: gerardcote:sympatico:ca at: 12-Mar-2002 8:42


Hi all, I don't know if this is really in order for this to be set here but I saw a cute "tree like map site generator" integrated inside the ELICA web site (as stated in their intro ELICA is "more than just another dialect of Logo" - read them to know more about). When looking at the HTML code for any of the 2 versions - Text and Graphics views - I apprciated the way they have done their design. Not to far

 [10/21] from: greggirwin:mindspring at: 12-Mar-2002 11:16


Good info Sunanda. It's always good to have an idea of how other people are doing things, and what they want. Thanks! --Gregg

 [11/21] from: greggirwin:mindspring at: 12-Mar-2002 11:02


Hi Carl, << Wouldn't using View's 'list be the way to go? It supports multiple faces per line. >> The problem is the need to create lots of faces for a large list or tree view. The alternative, using a List perhaps, is to create and destroy only as many faces as you need to display, which may be just as much work, but would have some benefits as well. I have a feeling that creating hundreds, or thousands, of faces, is less efficient (though more flexible) than using draw commands. --Gregg

 [12/21] from: greggirwin:mindspring at: 12-Mar-2002 11:23


Thanks Gerard! Another language site for my list... --Gregg

 [13/21] from: carl:cybercraft at: 13-Mar-2002 7:35


On 13-Mar-02, [riusa--email--it] wrote:
> Where can we find detailed information how to handle "list" object? > I found only brief examples.
This is the best I know of... http://www.rebolforces.com/archive/view099users.html =46rom when View was in Beta and before RT decided we needed 'text-list...
> Thanks a lot! >> On 12-Mar-02, Gregg Irwin wrote:
<<quoted lines omitted: 25>>
> PC > Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=276&d=12-3
-- Carl Read

 [14/21] from: ryanc:iesco-dms at: 12-Mar-2002 13:08


Check out this script I just made: http://www.sonic.net/~gaia/misc/testthing.r The technique is probably sufficient speedwise for most things, and allows for smooth scrolling and unique faces. It could probably be made alot faster with a little work. You might be able to do the same thing with list, but without the smooth scrolling. I would be curious of the speed difference, and bet that my routine is faster. --Ryan

 [15/21] from: greggirwin:mindspring at: 12-Mar-2002 23:02


Hi Ryan, et al << Check out this script I just made: >> Very cool! In return, here's a very quick hack that generates draw commands, just to see if this would work in a simple fashion. Obviously you could make it much smarter by not regenerating the whole set of drawing commands from scratch each time, and just poke new data into the block instead, but this works for a simple test. --Gregg cell-size: 120x21 map-slider-to-value: func [ "Converts a slider value between 0 and 1 to a value within a range." value [number!] "A value between 0 and 1." min-val [number!] "The minimum range value (if value = 0)." max-val [number!] "The maximum range value (if value = 1)." ][ max-val - min-val * value + min-val ] display-data: does [ v-base-val: map-slider-to-value v-sld/data 1 10000 h-base-val: map-slider-to-value h-sld/data 1 3000 clear head draw-cmds repeat row to-integer divide grd/size/y cell-size/y [ repeat col to-integer divide grd/size/x cell-size/x [ append draw-cmds compose [ text (to-pair reduce [ col - 1 * cell-size/x + 2 row - 1 * cell-size/y + 2 ]) (rejoin [ "R" to-integer (row - 1 + v-base-val) ":C" to-integer (col - 1 + h-base-val) ]) ] ] ] show grd ] lay: layout [ across space 1x1 grd: box 361x358 effect compose [grid (cell-size) draw []] v-sld: slider 15x358 [display-data] return h-sld: slider 361x15 [display-data] ] draw-cmds: grd/effect/draw display-data view lay

 [16/21] 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

 [17/21] from: sunandadh:aol at: 13-Mar-2002 6:53


Hi Gabrielle, Thanks very much for the suggestions:
> What about: > Style tgl Toggle 15x15 "-" "+" false > Style nde Text blue bold font-size 14
I tried a variant on the Toggle, as I need both 'false and 'true settings depending on whether a tree branch is open or closed. Style tglF Toggle 15x15 "-" "+" false Style tglT Toggle 15x15 "-" "+" true Unfortunately, it speeded the layout by under 1% -- not statistically significant, given the jitter. It is less feasible to use a Nde style as the attributes (font color, size, etc) vary from node to node.
> edge copy [] ; why? the copy should not be needed either > Do [Append ESINTREE-TEMP ESINTREE-TEMPITEM]
These are definite quality improvements in the code, but make no measurable difference in the time to Layout.
> 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.
Given you've mentioned memory, it's reminded me that the timings I've done on Layout are incredibly erratic. Where I've quoted a time (or an improvement in timing) it's on a first run in a new console session. Five minutes of use in the application can double the Layout times. I've tried 'recycle -- it makes no difference. Recycle/torture (what's it meant to do anyway?) tends to hang the application.
> - 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).
I'll give it a try! Thanks again for all the suggestions. Sunanda.

 [18/21] from: rotenca:telvia:it at: 13-Mar-2002 14:57


Hi, Gabriele
> 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.)
?? from the source of layout: parse specs [some [thru 'style val: parse specs [some [thru 'styles val: [ if not parse facets vid-rules [error "Invalid args:" start] Indeed layout parse every line in a forever loop and find the end of every line without parse. --- Ciao Romano

 [19/21] from: g:santilli:tiscalinet:it at: 15-Mar-2002 15:14


Hi Romano, On Wednesday, March 13, 2002, 2:57:28 PM, you wrote: RPT> parse specs [some [thru 'style val: RPT> parse specs [some [thru 'styles val: [ I didn't mean it is not using it at all. :) I just meant it is using it only for minor things. Sorry for the confusion. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [20/21] from: rotenca:telvia:it at: 15-Mar-2002 19:45


Hi Gabriele
> I didn't mean it is not using it at all. :) I just meant it is > using it only for minor things.
I do not agree. :-) I think there is little space for optimisation with parse without changing the dialect and making its syntax less free. But i can be wrong. BTW, there is a bug in layout: miss parens in the following vid-rule parse line: | 'sense set value block! [new/feel/engage: func [face action event] value] it should be: | 'sense set value block! ([new/feel/engage: func [face action event] value]) so the sense word could work. --- Ciao Romano

 [21/21] from: g:santilli:tiscalinet:it at: 15-Mar-2002 22:52


Hi Romano, On Friday, March 15, 2002, 7:45:45 PM, you wrote: RPT> I think there is little space for optimisation with parse without changing the RPT> dialect and making its syntax less free. RPT> But i can be wrong. For some aspects, I preferred CID. Anyway, with some care in avoiding copying blocks around (not easy, I should say, if you want to keep all the current features), it could be possible to make it faster IMHO. I don't know how much, anyway. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted