Issue Description:

Rapid triggering of Redstone conduit appears to cause a lot of chunk re-draws.

What happens:

While visiting Rorax' base on ForgeCraft, I noticed that I was seeing severe framerate drops (60+fps down to 30). Upon investigating, I noticed that the performance graph in the debug menu was showing large spikes during flashing of her insulated redstone conduit that is causing events in her RFTools Endergenic Generator system.

The spikes in this image directly correlate to changes in the Redstone.

The reason I suspect this is an issue with Ender IO over RF Tools is because the problem goes away when you are not looking at the chunk, and RFTools does not seem to have any changes to it's static rendering with the redstone pulses.

What you expected to happen:

I expect the framerate to be relatively stable.

Steps to reproduce:

1. Set down approximately 25-30 conduits.
2. Set up a clock (redstone or otherwise, shouldn't matter) to tick every 1.5 seconds.
3. When the clock pulses, trigger a series of other redstone pulses 3 ticks offset from each other (I.e, 3, 6, 9, 12, and 15 ticks)
4. Observe a series of FPS spikes as the pulses.

Affected Versions (Do not use "latest"):

• EnderIO: 3.0.0.43_alpha
• EnderCore: 0.4.0.26-alpha
• Minecraft: 1.9.4
• Forge: 12.17.0.1958

Your most recent log file where the issue was present:

[pastebin/gist/etc link here]
https://gist.github.com/AtomicBlom/f3b8df759a717464539c4d93fd068469

Sorry, that's just how redstone works. It triggers a chunk re-render when it changes state.

The conduits change color when active (like vanilla redstone), so have to be re-rendered
You could try putting facades on them but I suspect something recieving the changing signal will want to be re-rendered in response (e.g. a vanilla redstone lamp).
Not sure there is much we can do about this.

@CrazyPants it's a bit more than that. The redstone conduits reform their entire network every change. This means that each change will spam block updates throughout every connected block. So many chunk renders many times over.

Also, they were definitely not this bad on 1.7. I suspect there is some missing model caching going on and we are rebaking for every getQuads call. @HenryLoenwind can you check this?

We don't even have a model that does anything but return a ready-made list from the getQuads() call, so no need to check that.

Then, conduits cache their model for as long as they are unchanged. That means they will re-bake it in this case. The reason is quite simple: Figuring out how the conduit shall look (cache key) is more expensive than making the quads.

However, triggering redstone changes every 3 ticks will initiate re-renders for every tick. The first tick the signal changes, the next tick the conduits change and the third tick the target blocks change. The fourth tick the next change comes in...

And the size of the spike depends on what is in that chunk, which is not just conduits in that picture.

juuuust as an idea for weaker client computers, can you disable the fancy RS update rendering part as a whole from EIO conduits via config (client side only)

i just got by @HenryLoenwind 's explanation a hint what is going on with my old world :D (Especially the "chained update" sequence brought some other mods block into my mind that can cause this for me but only when triggered by the conduits)

well whoops my old world is 1.7.10 i would need a back patch to test if this was the issue, sorry to bother you

I have just finished a cleanup of the redstone conduit code and have (hopefully) significantly improved their behavior. Would you be able to update to the latest build and let me know if the issue is fixed? Anything version 3.0.0.45+ will have the new code.

I'll give it a shot after work tonight.

Sorry about @CrazyPants, I couldn't get a spare moment last night. Performance is MUCH better. 105 fps with facades, 70fps for naked RS conduits with 1 change per tick.

Thanks for your hard work.