overlapping workareas are very performance hungry

[hessenfarmer]

The changes merged in 9109 are very performance hungry.

on my old machine in the last master debug build the performance drops from 30 frames to 1.5 frames when selecting a small building.

Furthermore it seems as if to much areas are shown. (perhaps a cascading from other buildings)

[Benedikt Straub (nordfriese)]

I can confirm that there is a small impact on performance, but on my (rather slow) machine it is no stronger than when opening multiple building windows with workareas.

> Furthermore it seems as if to much areas are shown

Such cascades should not be possible, do you have a screenshot for this?

[Toni Förster (stonerl)]

I noticed that just showing the hunters hut working area itself (without overlapping) drops 15 - 20 frames.

[hessenfarmer (stephan-lutz)]

will try to make a screenshot tonight

[GunChleoc (gunchleoc)]

Can you attach a savegame for faster testing?

[hessenfarmer (stephan-lutz)]

here is the screenshot. A savegame is not necessary as this happens everytime. Maybe it is more evident in debug builds. However stonerl is right only showing one work area drops the frame rate by 15-20 frames.

[Benedikt Straub (nordfriese)]

Oftentimes it is not necessary to indicate overlaps, e.g. when placing a quarry I´m not interested in nearby mines and wells. Perhaps we should implement a hotkey for quick toggling whether overlaps will be highlighted or not so we only show them if desired.
Then people with slow machines can also just disable this feature…

Regarding the screenshot, I don´t see which buildings shouldn´t but do flare up here, can you point them out?

[Toni Förster (stonerl)]

But the problem isn't the indicated overlap. It's the new overlay itself. As I said here #2 the new overlay drops the frame rate up to 20fps for the woodcutter.

I don't think that my machine is particularly fast nor slow but TBH, the performance impact of this feature and the new overlay is way too high.

So adding a switch to en-/disable this feature doesn't solve the core problem.

[hessenfarmer (stephan-lutz)]

I believe now there is no cascading. Looking properly I found that mostly hunters were highlighted which have a very big working radius.
I agree with Stonerl as only selecting one overlay drops the frame rate massivly.
I think the overlays would be fine if the performance issue could be solved.

[Benedikt Straub (nordfriese)]

I´ll see what I can do…

[kaputtnik (franku)]

Slowing down the frame rate does only happen in debug builds. On my slow laptop this does not happen with a release build. On my fast(er) machine the framerate drops significantly with debug builds.

But for me the new feature isn't very useful. I guess for new players it is confusing. But i didn't spend much time to understand this feature. And if this feature has to be investigated for understanding, it has no benefit. Also i think the only reason for having this is the problematic thing between farms and foresters, but if a player can't see this during playing, he may do not understand this feature as well.

Sorry for my hard criticism...

[kaputtnik (franku)]

Playing a game with a debug stutters when trying to place a building and hovering over the building icons in the buildings menu. Result: No control over the mouse anymore.

While i think it can be useful for some buildings, i think it is useless for other building. Maybe we can get some speed improvements by limiting the shown workareas to be more useful?

In the attached screenshot i want to place a quarry. Does anyone guess which shown workareas belongs to which building? And which is important for placing the quarry?

After investigating i found that also 'workareas' of military buildings are shown. Is this informational when placing a quarry (or a well)?

Maybe restricting the shown workareas to buildings/workers which have a 'plant' program would be enough. Or, in case of military buildings: Show only 'workareas' of military buildings.

[Benedikt Straub (nordfriese)]

When placing a milsite or a port, you get all the workareas of other milsites, HQs and ports (own and enemy). When placing a productionsites, only own productionsites are shown.

> Maybe restricting the shown workareas to buildings/workers which have a 'plant' program would be enough.

Since worker programs do not and should not have name restrictions, and this would be hard to implement, -1. But I could add that every building defines the names of certain other buildings, and overlaps are indicated only for those…

> Playing a game with a debug stutters when trying to place a building and hovering over the building icons in the buildings menu.

My performance fix only masks the problem. I think making the actual calculation more efficient is not possible, so the costly calculation now is happening only when it is needed. This causes a small pause when moving around or showing/hiding a workarea.

[kaputtnik (franku)]

Thanks for your explanations :-)

> But I could add that every building defines the names of certain other buildings, and overlaps are indicated only for those…

If this is worth the work... I think the overlapping workareas are more confusing than helpful. Overlapping workareas can be shown also without this feature, one has to do more clicks though.

You are doing a great job, Benedict, also you spend much time to fix bug 1826504. And maybe i am the only one who has concerns with the result...

[hessenfarmer (stephan-lutz)]

The reason for having this was that players didn't want to have to do much clicks to show the work area. So we show it while in building mode. As stonerl said the overlap wasn't the main problem it was the new overlay itself rather than highlighting all nodes like before. Here I like the new overlay much more than the red dots with or without infill. So we should keep the overlay from my point of view especially as the last fix has reduced the impact much.

for the overlaps they are still quite confusing as it is not really clear which overlay belongs to which buildings. Furthermore not all overlaps are of interest. So maybe defining a list of buildings where the overlap should be shown would be good. In this case I would vote to have them as a table in the lua definition of a building. Because this could easily be adopted to personal likings and is the most extendable solution as the most maintainable.

Another Idea for the display might be to just show the overlapping sectors in the actual work area of the building to be placed. that would be even better if we could highlight the related buildings.

Additionally I noticed that the shortcut to toggle the overlapping overlay off works only in one direction. Pressing it again did not reactivate the overlay

[Benedikt Straub (nordfriese)]

I always disliked having to click a hundred times before placing a constructionsite in a densely built area... :)

> Furthermore not all overlaps are of interest. So maybe defining a list of buildings where the overlap should be shown would be good. In this case I would vote to have them as a table in the lua definition of a building.

This is the only place for them where they make sense IMHO :)

> Additionally I noticed that the shortcut to toggle the overlapping overlay off works only in one direction. Pressing it again did not reactivate the overlay

Reason for this is that I don´t know how to obtain the information which building you´re pointing at except on mouse-in events. Will try to fix it though…

> Another Idea for the display might be to just show the overlapping sectors in the actual work area of the building to be placed.

They are already stronger-coloured, the rest of the workarea is drawn much paler

> that would be even better if we could highlight the related buildings

+1 – suggestions how to indicate them appreciated :)

[GunChleoc (gunchleoc)]

Maybe we can automate detection of which building types are interesting for the overlaps? This way, changing a tribe's buildings roster would be easier, and we also prevent bugs caused by oversights.

The criterion would be that the worker will place an immovable on the map.

[hessenfarmer (stephan-lutz)]

> They are already stronger-coloured, the rest of the workarea is drawn much paler

I know it was just a suggestion to declutter the picture further. Only this would make identifiying the relted buildings even more difficult.

> +1 – suggestions how to indicate them appreciated :)

just brainstorming: firstoption would be to draw the complete sector of the workarea circle which is overlapping but this might be difficult although it would be clearly traceable to its origin.
next possibility would be having different colours just show a coloured circle overlay with radius 1 around the conflicting building and use the same colour for the overlap. Problem is we might run out of colours in a very dense area. on a second thought we could try this without colours just to see how it works maybe a radius of 2 would be ok as well.

> The criterion would be that the worker will place an immovable on the map.

Not necessarily. eg. for woodcutters it is interesting to not overlap much with other woodcutters but overlap a maximum with foresters. same for all supporting and producing couples. Frisian honey producer wants to overlap with buildings that produce flowering fields. mines should minimize overlapping with other mines of its type and so on so for me it is easier to have all the interdependencies in a lua table. that would make it easier to create a new tribe for example.

[GunChleoc (gunchleoc)]

I created some rules in the merge request off the changes there, but they can't handle flowering fields. So, this is getting too complicated - let's have the Lua definition after all.

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/592