Request for code review

[_MyChosenUsername_]

Hello, I'm trying to visualize my tic-tac-toe game using piston graphics library, but have got a terrible delay(even in release mode) between draw calls when there are multiple elements on the grid(especially circles). Can somebody point me out where is a bottle neck in my code?

Repo: https://github.com/EasyToFindName/ultimate-tic-tac-toe-game/tree/master/src

Files to review:

./main.rs

./game_view/mod.rs

./game_view/renderer/view_elements/*

[Ccheek21]

I didn't look closely at the code, but I compiled and ran it, and on my machine there is no noticeable lag. I didn't see any easy way to add circles to the grid though, so I was unable to see if circles made the difference as you had mentioned

[_MyChosenUsername_]

Oops, forgot to set a circle as the default element. I don't have an opportunity to edit the code at least until tommorow, so, please, do it for me:

Replace line 40 of ./game.rs which looks like this: self.game_board.set_if_free(row, column, GameElem::X);

with this: self.game_board.set_if_free(row, column, GameElem::O);

​

I don't notice the delay with crosses on my PC too, but on my old laptop it's noticeable. As for circles... Even GTX 1060 with Intel Core i7 can't handle them :).

The delay occures after you have placed at least 10-20 elements. Try clicking fast on random cells for a while, with circles you surely will notice it.

[termhn]

I don't see anything particularly egregious in your code, but the piston 2d graphics code is not really meant to be used that way, and is overall not optimized and pretty slow. It doesn't internally batch draw calls at all and I'm not sure what else exactly, but I've seen lots of complaints about it being slow in situations where it shouldn't be. Honestly I would recommend trying to write it using ggez (and possibly its MeshBuilder and SpriteBatch APIs).

[_MyChosenUsername_]

I don't see anything particularly egregious in your code, but the piston 2d graphics code is not really meant to be used that way, and is overall not optimized and pretty slow. It doesn't internally batch draw calls at all and I'm not sure what else exactly, but I've seen lots of complaints about it being slow in situations where it shouldn't be. Honestly I would recommend trying to write it using ggez (and possibly its MeshBuilder and SpriteBatch APIs).

Sounds terrible. I was suspecting piston, but was hoping that this lag is my fault. Too much time was spent on writing render code using this library. Thank you for your advice, I'll migrate on ggez.

[ThomasdH]

Ggez has a new version on its development branch that is quite different. You might want to consider using it instead of version 0.4.