[1.7.10] Significant frame rate drop when looking at block with custom model..

[Geforce]

Hello there,

 

I created a custom model for my furnace using Tabula by iChun. Everything works as it should, but there are some frame rate issues when looking at or near the block. If there are only one or two blocks down, it doesn't affect your FPS too much, but once you place ten or so down, your FPS can go from over 300+ to only 70 or 80 (and that's on a quite powerful GPU. Some computers which only run ~80 FPS can go as low as ~25 FPS). I don't use any large for loops or anything like that, so I don't see why the frame rate would drop so much.

 

Here's my code:

Model:

-Deactivated.

-Activated.

 

Renderer: Click me.

 

Thanks for reading!

~Geforce

[jabelar]

I'm not sure but in your renderTileEntityAt() method instead of creating new ResourceLocations each time, put them into a field during the constructor. ResourceLocation I expect does file access which would be an unnecessary perf hit.

 

P.S. Are you an NVIDIA fan? (I am too.)

[Draco18s]

I'm not sure but in your renderTileEntityAt() method instead of creating new ResourceLocations each time, put them into a field during the constructor. ResourceLocation I expect does file access which would be an unnecessary perf hit.

 

It's this.  You're causing Minecraft to load the texture from disk and reallocate memory for it (and then immediately discard it) every frame.

[Geforce]

Ah, that fixed it. Thanks!

[jabelar]

Ah, that fixed it. Thanks!

 

A lot of beginning programmers make the mistake of overusing the new instantiations on the fly. Don't keep creating the same thing over and over as it both affects perf (especially in the case where it includes file access) and also memory (as mentioned by Draco). If you've already got an instance, use it. If you know you need an instance over and over, make it a field for the class, or at least instantiate it outside the code that repeats.

[Draco18s]

I don't know why

new ResourceLocation(...)

takes so much time then.  Because it does.

[jabelar]

Also: There are 2 different constructors, once does some parsing of the input. Which do you use?

 

In the OP's code at top of thread he's using the one big string, which I would assume needs parsing.

 

It may not be the ResourceLocation itself but he's using that for binding the texture every time he renders as well. So that must do some sort of file access or at least cache access, right? Basically his code is binding a "new" (really repeating the old) texture every render tick.

[jabelar]

The ResourceLocation is just used as a key to look up the actual texture object. If you just create a new ResourceLocation or re-use the old one, you will get the same texture object, ResourceLocation implements equals and hashCode properly.

 

Sure, it looks like it handles avoiding the loading if the mapping is already present, but there is still a GL binding occurring repeatedly.

 

Based on this thread, and the numerous hits about gl bind texture performance issues when I search for them, I suspect you do want to avoid binding the texture unnecessarily: https://www.opengl.org/discussion_boards/showthread.php/182629-glBindTexture-has-deferred-processing

[jabelar]

But if you use a static ResourceLocation the texture will be bound just the same way...

 

Yeah, I know you can't get away without doing a binding for the render, but thought maybe the binding would still trigger something different if ResourceLocation was refreshed (same key or not). But looking through the code it like you said -- the binding should be same if ResourceLocation key is the same, whether or not the ResourceLocation is created freshly.