Glamour-Roassal RODraggableWithVelocity versus a large number of elements
Locked
 
|
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 |
|
|
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 > 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 |
|
|
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 |
|
|
--- 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 |
|
|
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |