Roassal3 unresponsive on Pharo 9+ with large diagrams

[JanBliznicenko]

Bug description When large Roassal 2 or 3 diagram is open, Pharo 8 is a little slow, but overall responsive and usable. Pharo 9 and 10 is WAY more unresponsive - processing mouse actions like dragging sometimes takes over 10 seconds or it completely freezes the image.

This issue is the same as https://github.com/pharo-project/pharo/issues/10515 , just with example for Roassal 3, not 2.

This issue is blocking us from moving to Pharo 9 and 10 with OpenPonk.

To Reproduce

1. Take two images: Clean Pharo 8 one and 9 (or 10) one. In both, do following:
2. Load latest Roassal3:

   [Metacello new
   baseline: 'Roassal3';
   repository: 'github://ObjectProfile/Roassal3';
   load ] on: MCMergeOrLoadWarning do: [:warning | warning load ].

3. Open large Roassal diagram:

   
   c := RSCanvas new.
   
   1 to: 30000 do: [ :i | 
       b1 := b2.
       b2 := RSBox new.
       b2 translateTo: (i * 10) @ (i * 10).
       b2 @ RSDraggable.
       c add: b2.
       b1
           ifNotNil: [ c add: (RSEdgeBuilder line edgeFrom: b1 to: b2) ] ].

c @ RSZoomableCanvasInteraction new.

c open.

4. Use mouse wheel to zoom out and in few times, for about 3 seconds

**Issue**
In Pharo 8, it is quite slow (like 2-5 FPS), but usable.
In Pharo 9 and 10, it usually does not update anything during the zooming itself and after you stop, it either does nothing or does the action after 5-15 seconds. The same applies for any action, like dragging of the boxes.

I am not sure what is at fault, but it seems to only affect Roasal, even if it does not depend on Roassal version at all. I actually think the problem is somewhere below Roassal, like graphics library, mouse event processing, VM...? Or maybe not, IDK :)

OS: Tested on Windows and Linux

Thank you for looking into the issue

[akevalion]

Thank you very much for this report, I will review it with the team after pharo days

[akevalion]

@JanBliznicenko Next week we are going to check this issue, because Carolina has covid, and we need her, to solve issues related to athens cairo and pharo

[JanBliznicenko]

No problem @akevalion. We (I and Peter Uhnak) are trying to find some optimizations as well, just for Roassal 2 in our case (because that is the one we still use). We found and fixed/circumvented some issues like duplicate searching for an element or issues regarding integer operations compared to floats.

[ 100000000 timesRepeat: [ 3.0 / 2 ] ] timeToRunWithoutGC: "3.0 / 2.0": 91 ms "3.0 / 2": 88 ms "3 / 2.0": 286 ms "3 / 2": 1373 ms

We will propose push request in a few days. But only for Roassal 2 for now, no capacity to do the same for Roassal 3 as well.

[akevalion]

@JanBliznicenko Thank you for your patience, I will let you know how this progress

[akevalion]

@JanBliznicenko here a little update

• Roassal is using cache for strokes.
• canvas now has antialiasing, disable antialiasing to have more fps
• selection over visible shapes, non visible shapes are not drawing.
• caching matrices, drawing process now is ussing AthensAffineTransform
• caching paths, each shape has a cache of its path.

Currently I am working to integrate the rendering tree, it is going to be a QuadTree. This data structure is going to handle the queries about the visible shapes and more important the contains point search. For now I this is a prototype. We are facing this issue with Pablo an Carolina

[JanBliznicenko]

@akevalion Great, looks promising. In the meantime, I prepared pull request for Roassal 2 with some improvements (efficiency, SVG export and few others): https://github.com/ObjectProfile/Roassal2/pull/64 I do not know yet which of these could and should be done in Roassal 3 as well.

[akevalion]

@JanBliznicenko here another update

• the big problem is the search algorithm of shapes
• roassal2 and roassal3 currently are using linear search for that
• I have created a prototype of R-Tree, kind of spatial search tree.

here you can see your example with 30k elements, each time the number one appears means that it process one event.

https://user-images.githubusercontent.com/10532890/166949376-2b5f6440-6770-4c5a-ade9-aa3fb8a69cbc.mov

with the new search tree prepared specially for this example you can handle 500k elements. Loading part is slow because it is building the search tree, after that the search is really fast

https://user-images.githubusercontent.com/10532890/166949696-f27f54e5-c37c-4e97-b209-9288798f606a.mov