Large number of interactive objects - Performance

[Borgel]

Im working with PixiJS 5.2.1 - WebGL 2 creating a hexgrid tile editor. 
The grid is composed of smaller segments of 'hexagon shaped' grids of hexagons. 
Essentially, my current testing environment is made up of 36 individual hexagon grids that make up the larger grid.
Each sub grid is composed of ~200 hexagons. 

Each hexagon is a interactive button. 
Here i ran into some performance issues, when moving the mouse over the grid.
When im not interacting with the scene, i have a stable 60 fps, but i dip down to ~20 fps when i move the mouse.

I have taken steps to improve the hit detection, by adding two layers of containers with circle hitareas.
First the 36 grids got their own circles, then each och the ~200 hexagons inside get their own circle, before the hex shape is hit tested.

So my worst case is:
Step 1: 
36 circle tests with  3 hits.
Step 2:
~600 circle tests with 3 hits
Step 3:
3 hexagon tests with 1 hit

When i reduce the number of subgrids to 19 the performance is greatly improved, now, with the same worst case i dip only to ~52 fps at most. 

To me this is very strange, it should only be 17 more checks when going from 19 subgrids to 36, but it looks like more is going on. 

Is there any behavior in pixi related to interactive buttons that i may have missed that would cause this? 

[Antriel]

If the hexagons are in a grid, you could avoid doing any hit tests by calculating the tile coordinates from cursor position.

[ivan.popelyshev]

You need custom containsPoint method on container that has all those tiles. Whether you draw with graphics, sprites or pixi-tilemap.

PixiJS does not have bounds optimizations inside, so it checks every tile in every container regardless of bounds.

[Borgel]

Im not sure i understand. 
I did add a PIXI.Circle to my containers hitArea.
Is this not enough? Because when i test it does seam to work.

I added a counter to the containsPoint function on my PIXI.Graphics and i logged ~16 total checks per 3 minutes while hovering over a tile, ie no extra checks. 
I also checked unique calls to containsPoint and i got a one to one hit for what i was hovering over. 

@Antriel
I am looking at a math based solution, but i wanted to understand what i was doing wrong. 

[ivan.popelyshev]

InteractionManager is simple enough, look into TreeSearch class: it just goes recursively and calls containsPoint. hitArea helps to stop it prematurely. You can add your own tree search, or override containsPoint, or hitArea.

[Borgel]

For anyone looking at similar problems in the future: 

I have resolved the performance issues I was having, but I have already moved away from having interactive tiles, opting instead to calculate the tile hit by a click event.
While the interaction manager did cause a performance issue, it was not the main issue I had. And to be fair I had more buttons in the scene then was reasonable. 

The main issue I was having was a lack of understanding of how The PIXI.Graphics class works. 
I was working under the false impression that 1 shape should be 1 graphics object. I thought this would be batched somehow and be quite quick to render, as all my shapes where the exact shape (Hexagons).
As it turns out, this was wrong.
Switching over from having 1 hex per graphics object to ~150 (A map chunk size I already used for other reasons) speed up rendering by a massive amount. 
Switching over to having multiple shapes in a single graphics object has increased performance by orders of magnitude.

I know my scenario may not be the most common, but anyone looking to make any type of tile based program would benefit from this approach. 
And if anyone know a space where this information has been spelled out before, please do link it, as I have been unable to find (or maybe understand) it. 
 

//Old/slow code
for ( grid in world )
	for ( hex in grid )
		grid.Container.AddChild( hex.Graphics );

//New/fast code
for ( grid in world )
	for ( hex in grid )
		grid.drawPolygon( hex.Points );