Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Ben Coman
This is a post in two parts. The first is purely Rossal and the second
is on the Glamour-Roassal integration.

Part One
RODraggableWithVelocity seems to have a problem overshooting the drag
distance with large numbers of elements. For example, referring to the
next script, with RODraggable only, if I drag the view background
sideways by a quarter-window-width, even though it takes a few seconds
to respond to a drag, the final position of the elements is a
quarter-window-width sideways. However with RODraggableWithVelocity,
doing the same action, I observe the elements briefly appear a
quarter-window-width sideways, then another quarter-window-width, then
another until the elements disappear off the side of the window.  This
behaviour disappears from this example by reducing to 1000 elements, but
occurs in my application with only 100 elements (plus an equal number of
edges).
-----
| rawView domain |
rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
domain := 1 to: 10000.
domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
ROVerticalLineLayout on: rawView elements.
rawView open
----

Part Two
Given that the paintingBlock of the GLMRoassalPresentation returned by
'GLMCompositePResentation>>rossal'
is passed a ROMondrianViewBuilder that has already added
RODraggableWithVelocity to the rawView, how do I remove that
RODraggableWithVelocity from the rawView?  The '@' method seems to work
differently between ROView (in processing the interaction straight away)
and ROElement (which seems to store the interaction for later processing
so it can be removed more easily).

In addition, could something like a GLMMorphicRoassalRawRenderer be
added to the Glamour-Roassal interface?  - which would pass an
unencumbered ROView to the paintingBlock.  It is not really a
Glamour-Roassal interface at the moment, more of a Glamour-Mondrian
interface.  I hacked up a GLMMorphicRoassalRawRenderer as best I could
as part of my experiment with "Interactive Roassal" but it wasn't very
elegant and I'm not sure it was correct.

cheers -ben
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Ben Coman
Ben Coman wrote:

> This is a post in two parts. The first is purely Rossal and the second
> is on the Glamour-Roassal integration.
>
> Part One
> RODraggableWithVelocity seems to have a problem overshooting the drag
> distance with large numbers of elements. For example, referring to the
> next script, with RODraggable only, if I drag the view background
> sideways by a quarter-window-width, even though it takes a few seconds
> to respond to a drag, the final position of the elements is a
> quarter-window-width sideways. However with RODraggableWithVelocity,
> doing the same action, I observe the elements briefly appear a
> quarter-window-width sideways, then another quarter-window-width, then
> another until the elements disappear off the side of the window.  This
> behaviour disappears from this example by reducing to 1000 elements,
> but occurs in my application with only 100 elements (plus an equal
> number of edges).
> -----
> | rawView domain |
> rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
> domain := 1 to: 10000.
> domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
> ROVerticalLineLayout on: rawView elements.
> rawView open
> ----
>
> Part Two
> Given that the paintingBlock of the GLMRoassalPresentation returned by
> 'GLMCompositePResentation>>rossal'
> is passed a ROMondrianViewBuilder that has already added
> RODraggableWithVelocity to the rawView, how do I remove that
> RODraggableWithVelocity from the rawView?  The '@' method seems to
> work differently between ROView (in processing the interaction
> straight away) and ROElement (which seems to store the interaction for
> later processing so it can be removed more easily).
>
> In addition, could something like a GLMMorphicRoassalRawRenderer be
> added to the Glamour-Roassal interface?  - which would pass an
> unencumbered ROView to the paintingBlock.  It is not really a
> Glamour-Roassal interface at the moment, more of a Glamour-Mondrian
> interface.  I hacked up a GLMMorphicRoassalRawRenderer as best I could
> as part of my experiment with "Interactive Roassal" but it wasn't very
> elegant and I'm not sure it was correct.
> cheers -ben
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
Alternatively, perhaps the existing infrastructure could be made to work
with
    browser transmit to: #graphic andShow: [ :a |
            a roassal
                view: ROView new ;
                title: 'Roassal Diagram' ;
                painting:
                [     :view :transmittedselection | ..etc..

The view: message here would override the default value set by the #view
method...
    ^view ifNil: [view := ROMondrianViewBuilder new]

I notice that GLMRoassalPresentation>>renderOn: has a flag 'This should
be the responsibility of the view'.
This method was one that I copied and modified for my
GLMRoassalRawPresentation removing calls to #applyLayout and
#populateMenuOn since they errored with ROView replacing
ROMondrianViewBuilder. Perhaps these lines might be pushed into a method
of ROMondrianViewBuilder, so the same method of ROView could be empty.

For my GLMMorphicRoassalRawRenderer>>render:  I copied from
GLMMorphicRoassalRenderer
changing the line...
    myMorph := ROMorph on: view stack
to...
    myMorph := ROMorph on: view
so perhaps that could also be pushed into a method on both ROView and
ROMondrianViewBuilder.

GLMMorphicRoassalRenderer>>actOnPresentationUpdate would need similar
attention since it has ROMondrianViewBuilder hardcoded (except I never
got a chance debug this for ROView, since the 'self halt' I inserted in
it never got activated)

Anyway, that is enough to chew on (and the limit of my grasp of the
overall architecture of the Glamour-Roassal interface).

cheers -ben
 
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Glamour-Roassal RODraggableWithVelocity versus a large number of elements

abergel
In reply to this post by Ben Coman
Scalability has been completely discarded so far. Even if it is difficult to make it right, we will get there on some point.
How severe is the problem you have faced? Can it wait until mid february or march ?

Cheers,
Alexandre


> Part One
> RODraggableWithVelocity seems to have a problem overshooting the drag distance with large numbers of elements. For example, referring to the next script, with RODraggable only, if I drag the view background sideways by a quarter-window-width, even though it takes a few seconds to respond to a drag, the final position of the elements is a quarter-window-width sideways. However with RODraggableWithVelocity, doing the same action, I observe the elements briefly appear a quarter-window-width sideways, then another quarter-window-width, then another until the elements disappear off the side of the window.  This behaviour disappears from this example by reducing to 1000 elements, but occurs in my application with only 100 elements (plus an equal number of edges).
> -----
> | rawView domain |
> rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
> domain := 1 to: 10000.
> domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
> ROVerticalLineLayout on: rawView elements.
> rawView open
> ----

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Ben Coman
RODraggableWithVelocity can wait.  The problem is severe but not critical.  I solved that issue by bypassing it and implementing Part Two with Glamour having the option of using a virgin ROView without RODraggableVelocity - see Moose Issue 900.  I would be keen for you (or Vanessa or Doru) to take an hour to have a look at that, even if you don't integrate it into the main repository at this time.   It is really just refactoring rather than something innovative and would be good to have some feedback I can consider in relation to refining it. 

---
In relation to scalability, a recently noticed that it seems that ALL elements and edges get translated from virtualToReal (or is it the other way around) before being passed to the FormCanvas for clipping and I wonder if you could gain some speed by first clipping with the ROCamera viewport translated into virtual co-ordinates. 

Btw, could you enhance the comment in the methods #realToVirtualPoint and #virtualToRealPoint to more clearly describe what 'real' and 'virtual' .  I get a bit lost trying to work it out myself.

cheers -ben

Alexandre Bergel wrote:
Scalability has been completely discarded so far. Even if it is difficult to make it right, we will get there on some point. 
How severe is the problem you have faced? Can it wait until mid february or march ?

Cheers,
Alexandre


  
Part One
RODraggableWithVelocity seems to have a problem overshooting the drag distance with large numbers of elements. For example, referring to the next script, with RODraggable only, if I drag the view background sideways by a quarter-window-width, even though it takes a few seconds to respond to a drag, the final position of the elements is a quarter-window-width sideways. However with RODraggableWithVelocity, doing the same action, I observe the elements briefly appear a quarter-window-width sideways, then another quarter-window-width, then another until the elements disappear off the side of the window.  This behaviour disappears from this example by reducing to 1000 elements, but occurs in my application with only 100 elements (plus an equal number of edges).
-----
| rawView domain |
rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
domain := 1 to: 10000.
domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
ROVerticalLineLayout on: rawView elements.
rawView open
----
    

  


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Ben Coman
Well it definitely seems like the drawing of text for ROLabel is what is slowing things down.  I thought it wouldn't be too hard to make a simple/naive caching ROLabel for my own purposes but the results are a bit ambiguous and disappointing.  I'll drop this for now but just present what I did in case anyone has thoughts on a way forward later.

First I put a 'self haltOnce' in ROLabel>>drawOn:for:  Then executed the following...
---
view := ROView new.
view add: (ROElement on: '1') + ROLabel.
view open
---
so that in the debugger I had access to a valid aCanvas and aROElement.  Then in the debugger bottom-right pane (what would you call this one?) I executed the following code....
----
Smalltalk garbageCollect.
MessageTally spyOn:
[     | tmpCanvas tmpElement tmpLabel |
    tmpCanvas := aCanvas.         ""from the debugger context so as to not look up the variable each loop""
    tmpElement := aROElement.   "from the debugger context so as to not look up the variable each loop"
    tmpLabel := ROLabel new.    "or ROCachedLabel new"
    10000 timesRepeat: [ tmpLabel drawOn: tmpCanvas for: tmpElement ]
]
----
against both of the methods #ROLabel and #ROCachedLabel listed below, with the tally results for each at the bottom of this post.
Some observations...
1. 55% was spent in #heightOfString primitives, 30% in canvas>>drawString pimitives, 8% by #topleft.
2. Assuming static text, ROCachedLabel eliminates #heightOfString from the loop - but ROLabel took 4753 msec and ROCachedLabel still took 4546.  I was really surprised at the lack of improvement after taking #heightOfString out of the loop.
3. I believe (at the moment) that #position and #topLeft are equivalent, and changed this for a simple 8% gain.
4. ROPharoCanvas>>drawString:at:color: remained fairly constant (~32%). 
5. Suddenly for ROCachedLabel the '+' message has sucked up all the 66% previously spent in #heightOfString and #topleft  !!!! Why ?  ROLabel must have been doing at least the same amount of additions and ROCachedLabel but '+' didn't even appear in the spy result for ROLabel.

So I am somewhat disappointed and confused at the results. :)


The two implementations being compared...
-----
ROLabel>>drawOn: aCanvas for: aROElement
    | str runner |
    self haltOnce.
    str := self textAdaptedFor: aROElement.
    runner := aROElement topLeft + ROPlatform current fontOrganizerClass offsetWhenDrawing.
    str linesDo: [ :line |
        aCanvas drawString: line at: runner color: (self colorFor: aROElement ).
        runner := runner + (0 @ (self heightOfString: line))  
    ]
-----
which I modified to...
--------
ROCachedLabel>>drawOn: aCanvas for: aROElement
    | runner |
    self haltOnce.
    cachedText ifNil:  "all cached variables are instance variables"
    [     cachedText := self textAdaptedFor: aROElement .
        cachedLines := OrderedCollection new.
        cachedText linesDo: [ :line | cachedLines add: { line . (0 @ (self heightOfString: line)) }  ].
        cachedColor := self colorFor: aROElement .
        cachedOffsetWhenDrawing := ROPlatform current fontOrganizerClass offsetWhenDrawing.
    ].
    runner := aROElement position + cachedOffsetWhenDrawing.
    cachedLines do:
    [    :cachedLineParts | | height2 |
        height2 :=  cachedLineParts second.
        aCanvas drawString: cachedLineParts first at: runner color: cachedColor.
        runner := runner + height2.
    ]
--------

MessageTally results....
======
ROLabel - 4746 tallies, 4753 msec.
**Tree**
--------------------------------
Process: (40s) 1047789568: nil
--------------------------------
56.1% {2665ms} ROLabel(ROAbstractLabel)>>heightOfString:
  |55.4% {2631ms} primitives
31.5% {1497ms} ROPharoCanvas>>drawString:at:color:
  |31.0% {1475ms} FormCanvas(Canvas)>>drawString:at:font:color:
  |  31.0% {1474ms} FormCanvas>>drawString:from:to:at:font:color:
  |    30.2% {1434ms} StrikeFont>>displayString:on:from:to:at:kern:
  |      30.1% {1432ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern:
  |        30.1% {1431ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:
  |          30.1% {1429ms} primitives
8.0% {380ms} ROElement>>topLeft
  8.0% {380ms} ROElement>>bounds
    7.9% {375ms} ROLabel(ROAbstractLabel)>>extentFor:
      7.8% {370ms} ROLabel(ROAbstractLabel)>>preferedExtentFor:
        7.1% {338ms} ROLabel(ROAbstractLabel)>>widthFor:
          6.4% {305ms} ROLabel(ROAbstractLabel)>>longestTextLineFor:
            6.1% {289ms} ROLabel(ROAbstractLabel)>>linesOf:
              2.6% {124ms} ByteString(SequenceableCollection)>>,
                |1.3% {62ms} ByteString(SequenceableCollection)>>copyReplaceFrom:to:with:
                |  |1.2% {55ms} ByteString class(String class)>>new:
                |1.3% {62ms} primitives
              2.2% {104ms} ByteString(SequenceableCollection)>>do:

**Leaves**
55.5% {2636ms} ROLabel(ROAbstractLabel)>>heightOfString:
30.1% {1429ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:
3.3% {156ms} ByteString(SequenceableCollection)>>do:
1.6% {76ms} ByteString class(String class)>>new:
1.6% {74ms} ByteString(SequenceableCollection)>>,

**Memory**
    old            +0 bytes
    young        +778,268 bytes
    used        +778,268 bytes
    free        -778,268 bytes

**GCs**
    full            0 totalling 0ms (0.0% uptime)
    incr        29 totalling 48ms (1.0% uptime), avg 2.0ms
    tenures        0
    root table    0 overflows

======
ROCachedLabel - 4541 tallies, 4546 msec.

**Tree**
--------------------------------
Process: (40s)  570687488: nil
--------------------------------
66.2% {3007ms} Point>>+
33.7% {1532ms} ROPharoCanvas>>drawString:at:color:
  33.4% {1517ms} FormCanvas(Canvas)>>drawString:at:font:color:
    33.3% {1515ms} FormCanvas>>drawString:from:to:at:font:color:
      32.6% {1484ms} StrikeFont>>displayString:on:from:to:at:kern:
        32.6% {1484ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern:
          32.6% {1484ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:

**Leaves**
66.3% {3013ms} Point>>+
32.6% {1484ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:

**Memory**
    old            +0 bytes
    young        +811,308 bytes
    used        +811,308 bytes
    free        -811,308 bytes

**GCs**
    full            0 totalling 0ms (0.0% uptime)
    incr        6 totalling 9ms (0.0% uptime), avg 2.0ms
    tenures        0
    root table    0 overflows
=====


regards -ben



Ben Coman wrote:
RODraggableWithVelocity can wait.  The problem is severe but not critical.  I 
solved that issue by bypassing it and implementing Part Two with Glamour having 
the option of using a virgin ROView without RODraggableVelocity - see Moose 
Issue 900.  I would be keen for you (or Vanessa or Doru) to take an hour to have 
a look at that, even if you don't integrate it into the main repository at this 
time.   It is really just refactoring rather than something innovative and would 
be good to have some feedback I can consider in relation to refining it. 

---
In relation to scalability, a recently noticed that it seems that ALL elements 
and edges get translated from virtualToReal (or is it the other way around) 
before being passed to the FormCanvas for clipping and I wonder if you could 
gain some speed by first clipping with the ROCamera viewport translated into 
virtual co-ordinates. 

Btw, could you enhance the comment in the methods #realToVirtualPoint and 
#virtualToRealPoint to more clearly describe what 'real' and 'virtual' .  I get 
a bit lost trying to work it out myself.

cheers -ben

Alexandre Bergel wrote:
> Scalability has been completely discarded so far. Even if it is difficult to make it right, we will get there on some point. 
> How severe is the problem you have faced? Can it wait until mid february or march ?
>
> Cheers,
> Alexandre
>
>
>   
>> Part One
>> RODraggableWithVelocity seems to have a problem overshooting the drag distance with large numbers of elements. For example, referring to the next script, with RODraggable only, if I drag the view background sideways by a quarter-window-width, even though it takes a few seconds to respond to a drag, the final position of the elements is a quarter-window-width sideways. However with RODraggableWithVelocity, doing the same action, I observe the elements briefly appear a quarter-window-width sideways, then another quarter-window-width, then another until the elements disappear off the side of the window.  This behaviour disappears from this example by reducing to 1000 elements, but occurs in my application with only 100 elements (plus an equal number of edges).
>> -----
>> | rawView domain |
>> rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
>> domain := 1 to: 10000.
>> domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
>> ROVerticalLineLayout on: rawView elements.
>> rawView open
>> ----
>>     
>
>   

  

_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Glamour-Roassal RODraggableWithVelocity versus a large number of elements

Ben Coman
So I simplified it even further as ROCachedSingleLineLabel and still get a similar execution time of 4342.  MessageTally now shows the containing timesRepeat loop
as taking 65% with the percentage for drawString primitives still relatively unchanged. Not quite sure what to make of it.
------------
ROCachedSingleLineLabel>>drawOn: aCanvas for: aROElement
    | runner |
    cachedText ifNil:
    [     cachedText := self textAdaptedFor: aROElement .
        cachedColor := self colorFor: aROElement .
        cachedOffsetWhenDrawing := ROPlatform current fontOrganizerClass offsetWhenDrawing.
    ].
    aCanvas drawString: cachedText at: (aROElement position + cachedOffsetWhenDrawing) color: cachedColor.
-------------
with a MessageTally result of...
 - 4340 tallies, 4342 msec.

**Tree**
--------------------------------
Process: (40s)  991952896: nil
--------------------------------
34.4% {1496ms} ROPharoCanvas>>drawString:at:color:
  34.2% {1486ms} FormCanvas(Canvas)>>drawString:at:font:color:
    34.2% {1485ms} FormCanvas>>drawString:from:to:at:font:color:
      33.6% {1461ms} StrikeFont>>displayString:on:from:to:at:kern:
        33.6% {1460ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern:
          33.6% {1459ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:
            33.5% {1454ms} primitives

**Leaves**
65.4% {2841ms} SmallInteger(Integer)>>timesRepeat:
33.5% {1454ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:

**Memory**
    old            +0 bytes
    young        +753,036 bytes
    used        +753,036 bytes
    free        -753,036 bytes

**GCs**
    full            0 totalling 0ms (0.0% uptime)
    incr        6 totalling 13ms (0.0% uptime), avg 2.0ms
    tenures        0
    root table    0 overflows

regards -ben

Ben Coman wrote:
Well it definitely seems like the drawing of text for ROLabel is what is slowing 
things down.  I thought it wouldn't be too hard to make a simple/naive caching 
ROLabel for my own purposes but the results are a bit ambiguous and 
disappointing.  I'll drop this for now but just present what I did in case 
anyone has thoughts on a way forward later.

First I put a 'self haltOnce' in ROLabel>>drawOn:for:  Then executed the 
following...
---
view := ROView new.
view add: (ROElement on: '1') + ROLabel.
view open
---
so that in the debugger I had access to a valid aCanvas and aROElement.  Then in 
the debugger bottom-right pane (what would you call this one?) I executed the 
following code....
----
Smalltalk garbageCollect.
MessageTally spyOn:
[     | tmpCanvas tmpElement tmpLabel |
    tmpCanvas := aCanvas.         ""from the debugger context so as to not look 
up the variable each loop""
    tmpElement := aROElement.   "from the debugger context so as to not look up 
the variable each loop"
    tmpLabel := ROLabel new.    "or ROCachedLabel new"
    10000 timesRepeat: [ tmpLabel drawOn: tmpCanvas for: tmpElement ]
]
----
against both of the methods #ROLabel and #ROCachedLabel listed below, with the 
tally results for each at the bottom of this post.
Some observations...
1. 55% was spent in #heightOfString primitives, 30% in canvas>>drawString 
pimitives, 8% by #topleft.
2. Assuming static text, ROCachedLabel eliminates #heightOfString from the loop 
- but ROLabel took 4753 msec and ROCachedLabel still took 4546.  I was really 
surprised at the lack of improvement after taking #heightOfString out of the loop.
3. I believe (at the moment) that #position and #topLeft are equivalent, and 
changed this for a simple 8% gain.
4. ROPharoCanvas>>drawString:at:color: remained fairly constant (~32%). 
5. Suddenly for ROCachedLabel the '+' message has sucked up all the 66% 
previously spent in #heightOfString and #topleft  !!!! Why ?  ROLabel must have 
been doing at least the same amount of additions and ROCachedLabel but '+' 
didn't even appear in the spy result for ROLabel.

So I am somewhat disappointed and confused at the results. :)


The two implementations being compared...
-----
ROLabel>>drawOn: aCanvas for: aROElement
    | str runner |
    self haltOnce.
    str := self textAdaptedFor: aROElement.
    runner := aROElement topLeft + ROPlatform current fontOrganizerClass 
offsetWhenDrawing.
    str linesDo: [ :line |
        aCanvas drawString: line at: runner color: (self colorFor: aROElement ).
        runner := runner + (0 @ (self heightOfString: line))  
    ]
-----
which I modified to...
--------
ROCachedLabel>>drawOn: aCanvas for: aROElement
    | runner |
    self haltOnce.
    cachedText ifNil:  "all cached variables are instance variables"
    [     cachedText := self textAdaptedFor: aROElement .
        cachedLines := OrderedCollection new.
        cachedText linesDo: [ :line | cachedLines add: { line . (0 @ (self 
heightOfString: line)) }  ].
        cachedColor := self colorFor: aROElement .
        cachedOffsetWhenDrawing := ROPlatform current fontOrganizerClass 
offsetWhenDrawing.
    ].
    runner := aROElement position + cachedOffsetWhenDrawing.
    cachedLines do:
    [    :cachedLineParts | | height2 |
        height2 :=  cachedLineParts second.
        aCanvas drawString: cachedLineParts first at: runner color: cachedColor.
        runner := runner + height2.
    ]
--------

MessageTally results....
======
ROLabel - 4746 tallies, 4753 msec.
**Tree**
--------------------------------
Process: (40s) 1047789568: nil
--------------------------------
56.1% {2665ms} ROLabel(ROAbstractLabel)>>heightOfString:
  |55.4% {2631ms} primitives
31.5% {1497ms} ROPharoCanvas>>drawString:at:color:
  |31.0% {1475ms} FormCanvas(Canvas)>>drawString:at:font:color:
  |  31.0% {1474ms} FormCanvas>>drawString:from:to:at:font:color:
  |    30.2% {1434ms} StrikeFont>>displayString:on:from:to:at:kern:
  |      30.1% {1432ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern:
  |        30.1% {1431ms} 
GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:
  |          30.1% {1429ms} primitives
8.0% {380ms} ROElement>>topLeft
  8.0% {380ms} ROElement>>bounds
    7.9% {375ms} ROLabel(ROAbstractLabel)>>extentFor:
      7.8% {370ms} ROLabel(ROAbstractLabel)>>preferedExtentFor:
        7.1% {338ms} ROLabel(ROAbstractLabel)>>widthFor:
          6.4% {305ms} ROLabel(ROAbstractLabel)>>longestTextLineFor:
            6.1% {289ms} ROLabel(ROAbstractLabel)>>linesOf:
              2.6% {124ms} ByteString(SequenceableCollection)>>,
                |1.3% {62ms} 
ByteString(SequenceableCollection)>>copyReplaceFrom:to:with:
                |  |1.2% {55ms} ByteString class(String class)>>new:
                |1.3% {62ms} primitives
              2.2% {104ms} ByteString(SequenceableCollection)>>do:

**Leaves**
55.5% {2636ms} ROLabel(ROAbstractLabel)>>heightOfString:
30.1% {1429ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:
3.3% {156ms} ByteString(SequenceableCollection)>>do:
1.6% {76ms} ByteString class(String class)>>new:
1.6% {74ms} ByteString(SequenceableCollection)>>,

**Memory**
    old            +0 bytes
    young        +778,268 bytes
    used        +778,268 bytes
    free        -778,268 bytes

**GCs**
    full            0 totalling 0ms (0.0% uptime)
    incr        29 totalling 48ms (1.0% uptime), avg 2.0ms
    tenures        0
    root table    0 overflows

======
ROCachedLabel - 4541 tallies, 4546 msec.

**Tree**
--------------------------------
Process: (40s)  570687488: nil
--------------------------------
66.2% {3007ms} Point>>+
33.7% {1532ms} ROPharoCanvas>>drawString:at:color:
  33.4% {1517ms} FormCanvas(Canvas)>>drawString:at:font:color:
    33.3% {1515ms} FormCanvas>>drawString:from:to:at:font:color:
      32.6% {1484ms} StrikeFont>>displayString:on:from:to:at:kern:
        32.6% {1484ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern:
          32.6% {1484ms} 
GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:

**Leaves**
66.3% {3013ms} Point>>+
32.6% {1484ms} GrafPort(BitBlt)>>basicDisplayString:from:to:at:strikeFont:kern:

**Memory**
    old            +0 bytes
    young        +811,308 bytes
    used        +811,308 bytes
    free        -811,308 bytes

**GCs**
    full            0 totalling 0ms (0.0% uptime)
    incr        6 totalling 9ms (0.0% uptime), avg 2.0ms
    tenures        0
    root table    0 overflows
=====


regards -ben



Ben Coman wrote:
> RODraggableWithVelocity can wait.  The problem is severe but not critical.  I 
> solved that issue by bypassing it and implementing Part Two with Glamour having 
> the option of using a virgin ROView without RODraggableVelocity - see Moose 
> Issue 900.  I would be keen for you (or Vanessa or Doru) to take an hour to have 
> a look at that, even if you don't integrate it into the main repository at this 
> time.   It is really just refactoring rather than something innovative and would 
> be good to have some feedback I can consider in relation to refining it. 
>
> ---
> In relation to scalability, a recently noticed that it seems that ALL elements 
> and edges get translated from virtualToReal (or is it the other way around) 
> before being passed to the FormCanvas for clipping and I wonder if you could 
> gain some speed by first clipping with the ROCamera viewport translated into 
> virtual co-ordinates. 
>
> Btw, could you enhance the comment in the methods #realToVirtualPoint and 
> #virtualToRealPoint to more clearly describe what 'real' and 'virtual' .  I get 
> a bit lost trying to work it out myself.
>
> cheers -ben
>
> Alexandre Bergel wrote:
> > Scalability has been completely discarded so far. Even if it is difficult to make it right, we will get there on some point. 
> > How severe is the problem you have faced? Can it wait until mid february or march ?
> >
> > Cheers,
> > Alexandre
> >
> >
> >   
> >> Part One
> >> RODraggableWithVelocity seems to have a problem overshooting the drag distance with large numbers of elements. For example, referring to the next script, with RODraggable only, if I drag the view background sideways by a quarter-window-width, even though it takes a few seconds to respond to a drag, the final position of the elements is a quarter-window-width sideways. However with RODraggableWithVelocity, doing the same action, I observe the elements briefly appear a quarter-window-width sideways, then another quarter-window-width, then another until the elements disappear off the side of the window.  This behaviour disappears from this example by reducing to 1000 elements, but occurs in my application with only 100 elements (plus an equal number of edges).
> >> -----
> >> | rawView domain |
> >> rawView := ROView new @ RODraggable  " @ RODraggableWithVelocity "  .
> >> domain := 1 to: 10000.
> >> domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
> >> ROVerticalLineLayout on: rawView elements.
> >> rawView open
> >> ----
> >>     
> >
> >   
>
>   
> --------------------------------------------------------------------------------
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>   

  

_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev