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