Experimenting with Window.update

[Mike]

I was experimenting with window x, y, width, and height, and I found something interesting about them.

I tried the following code:

Spoiler

class Window alias test_update update def update test_update #self.x += 0 #self.x += 0 #self.x += 0 #self.x += 0 #self.y += 0 #self.y += 0 #self.y += 0 #self.y += 0 #self.width += 0 #self.width += 0 #self.width += 0 #self.width += 0 self.height += 0 self.height += 0 self.height += 0 self.height += 0 endend

And based on the result that I got, while the x and y operator methods don't affect anything, the width and height operator methods will slow down your game by speed / 2n (with n is equal to how many times operator method is called, and of course 2-n is a rough rounding).

Does anyone has any clues about it? 

Edit: 

Btw,

use the following code if you want to see how your game is moving frame by frame.

Spoiler

class Window  alias test_update update    def update    test_update    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0    self.height += 0  endend

 

[Engr. Adiktuzmiko]

I don't seem to get the slow down when using those, not even a single spec of slow down... well at least I don't run .height and .width on update... so it might be because of the fact that ur running it on update, meaning it runs every frame...

 

[Tsukihime]

Lol that's pretty interesting, just one height update caused my FPS to go from 120 to 15. Well, that's cause there are 7 windows on the map scene and you put in the Window class.


When I moved it to the message window, it went from 120 to 70 for a single height update every frame.


The window must be doing something really questionable, which sort of indicates that you shouldn't be messing around with your windows.

 

[Engr. Adiktuzmiko]

anyways, most things that concerns graphics seem to be normally slow and as such not really recommended to be used per frame... I think all the more since RM seems to utilize only the CPU (from other threads?) and from what I read from other forums, having the CPU perform the graphic tasks isn't really nice...

 

[Mike]

Well, if we could pin-point which graphical tweaks make the performance slower / much slower, we could find solutions to reduce the performance cost from our graphic scripts. : P

self.x and self.y don't have much performance cost compared to self.width and self.height. I'm guessing that self.width and height have something to do with the window's content, and tweaking them would perform unknown number of methods. Hmmm.

Oh well, I'll let you folks know when I found other interesting stuffs about RGSS.

 

[Engr. Adiktuzmiko]

well, some of the contents do adjust with window size... plus the Window's bitmap (the one called contents) itself will adjust itself based on the window size...

 

[Tsukihime]

well, some of the contents do adjust with window size... plus the Window's bitmap (the one called contents) itself will adjust itself based on the window size...

Do you have evidence of this? I've never heard that before but that sounds a bit strange.


I know you made a post about how window contents and GUI's automatically adjust themselves when you re-size the window but I didn't think you were talking about an existing function.

 

[Engr. Adiktuzmiko]

EDIT: I forgot that I made them refresh...

 

[Tsukihime]

`create_contents` re-builds the contents bitmap based on width and height, yes.


Updating your width and height does not call that method automatically.

 

[Engr. Adiktuzmiko]

yeah... actually, I'm wrong... I forgot that I actually made my windows to refresh... thus calling that method...

 

[Mithran]

Good find.


The height and width operators are actually much slower than I anticipated. The slowdown is at the metadata level, though, which probably contains instructions to reconstructs the entire window regardless of whether it is even visible or not. Since windows don't normally need to change size and shape during run time, this isn't something we would normally optimize around. The accessor probably should have a safeguard that prevents it from needing to perform the metadata level stuff if the value is the same, though, that is easy enough to implement.


If you need to actually change the height or width of a window often enough to cause slowdown, consider only performing the action once every n frames. If you really wanted it to be smooth, you could fake the look of a window by constructing it with Sprites, but those also have some serious bottlenecks so that would be an extreme case.

 

[Mike]

Good find.

The height and width operators are actually much slower than I anticipated. The slowdown is at the metadata level, though, which probably contains instructions to reconstructs the entire window regardless of whether it is even visible or not. Since windows don't normally need to change size and shape during run time, this isn't something we would normally optimize around. The accessor probably should have a safeguard that prevents it from needing to perform the metadata level stuff if the value is the same, though, that is easy enough to implement.

If you need to actually change the height or width of a window often enough to cause slowdown, consider only performing the action once every n frames. If you really wanted it to be smooth, you could fake the look of a window by constructing it with Sprites, but those also have some serious bottlenecks so that would be an extreme case.

Yea, that's basically what I do with an additional safeguard, where it will still perform that metadata level stuff for the first update after initialization regardless any change. xD