-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process should be almost idle but the CPU load is 66%. #22
Comments
Thank you for report! |
Unfortunately no change. Good news: the bug is easy to reproduce: just
loose :)
|
I thought it was a problem with fps. Ok, I'll try fix it when come home. |
Actually. I observed the same CPU load after starting (see screenshot). |
I checked it on various fps and found correlation between it and cpu usage. |
I suppose, the problem in piston implementation itself. For instance, Piston redraw all widgets on window all time earlier. A few last versions they implemented some improvements in usage of cpu. IMHO, we should move to last piston version to improve it. |
This is good idea, I will try do it tonight. |
On my configuration, I have 7% load cpu by default and it increase to 14% if I set field size 50x50 cells. It seems that redrawing of field requires too much cpu time. If I comment line self.field.draw(c, g, field_rect, &mut self.glyphs); in method |
I know that it is redrawing:
The question is - can we fix it, or not? I have an idea - to change game to event driven. Redraw only if something happened, it will solve the problem, but we will be unable to draw animation if we, may be, want it in future. I will try it on this weekend |
@Vinatorul, wait. There is a hope that this approach give us enough performance results now and ability to draw pictures and animations in future. I try to do it at the weekend. |
My attempt is fail. I tried to make prerendered cells in sprites of scene. Unfortunately, I didn't find any API for render text in textures or images and so that I just prerender rectangles for cells and draw it by scene-object. It didn't get any valuable effect and cpu load stay almost the same. If ellimate drawing of numbers cpu load became less around 10% from original cpu load. It seems to me that big part of cpu load is copying of pixels for drawing. |
@xilec I think event-driven solution will be suitable for such game |
@Vinatorul Definetly, event-driven approach is the most efficient solution for this game, but how do you want achieve this. As I understand Piston don't give such option. At least, when i tried to not redraw picture, if user don't execute any input, it start blinking. |
Any news here? |
Unfortunately, still no ideas. |
Piston use double buffering for drawing in 2d mode. RenderState is used for redrawing both buffer when it needs. On my computer, CPU load dropped from 6-7% percents to 0.3% without any input with default settings. In general, it works fine, but there are some case that needed addition handling: window resizing, stoping timer after changing field size or mine count and may be something else.
Piston use double buffering for drawing in 2d mode. RenderState is used for redrawing both buffer when it needs. On my computer, CPU load dropped from 6-7% percents to 0.3% without any input with default settings. In general, it works fine, but there are some case that needed addition handling: window resizing, stoping timer after changing field size or mine count and may be something else.
When I tried naive redrawing only when user do some input, window started blinking because inside the piston event loop implemented double buffering approach and I redraw just 1 buffer. Now, when picture is redrawn on both buffer, window picture looks good without such cpu load. |
Works for me! :) The load dropped from approx. 90% to 5%. |
@getreu look into chapter "Double buffering in computer graphics" on this wiki page. The same approach is used in implementation of PistonWindow. Method |
@xilec I got the point. If I understood right the employed technique here is Page flipping. |
imp: Implement redrawing when it needs for fixing #22.
Process should be almost idle at the end of the game, but the CPU load is 66%.
!
The text was updated successfully, but these errors were encountered: