Scrolling Through REI Extremely Lag when Reach Forgero Item List
ardissaps opened this issue ยท 15 comments
Do the icon high resolution or not compressed or something. REI lagged so much when looking at Forgero Item
The FPS return normal when scroll to another page that no Forgero item.
Lets say Forgero on page 18 and 19, whole FPS reduced to 7-9 FPS when on that page, but FPS return to normal if not in that page.
I have pretty old hardware i7-4790K + 980 TI (around 2015) using complementary shader with default option.
As additional information I am using ARRP that included on BRRP, they say they fixed bug from ARRP.
Alright, hardware seems decent enough. Looks like there is a severe lack of optimization present with Forgero tools.
BRRP should not affect performance, but it's nice info.
Yeah this is probably due to how Forgero items are rendered. It is not really optimized and not cached yet. Which specs are your pc? I don't think I have encountered to many performance issues because my development pc is a little overspecced. Might be a good idea for me to test performance on lower tier hardware.
This issue might take a while to fix as it requires me to rework parts of the modelling system, and the rendering pipeline. This also relates to #8. I know very little when it comes to rendering, so don't expect a lot of progress soon.
Can confirm that this is happening on my end too, my fps normally sits around the 300 mark, and drops to the 10's when viewing any forgero items
Looks like it's optimization time! I am currently focusing on the 0.10.0 update, but this is a serious bottleneck. If I can find a simple way to implement a fix for this, I'll implement it and release it as 0.9.3. I am not sure exactly when this will be ready, bit I am working on it.
Thanks for highlighting the issue!
I did some testing, but I was not able to reproduce as severe of an issue as you reported. This most likely comes down to hardware. I was also only able to reproduce this issue on Windows. Linux does not seem to struggle with this at all. This makes it a little harder to debug as I am not able to see if any changes made impacts the issue. Older hardware will likely struggle with recreating Forgero tools from NBT data, so it seems like I'll have to implement caching in a variety of places.
I did some testing, but I was not able to reproduce as severe of an issue as you reported. This most likely comes down to hardware. I was also only able to reproduce this issue on Windows. Linux does not seem to struggle with this at all. This makes it a little harder to debug as I am not able to see if any changes made impacts the issue. Older hardware will likely struggle with recreating Forgero tools from NBT data, so it seems like I'll have to implement caching in a variety of places.
Or could be REI side problem or my huge modlist. Maybe you can try to run it in VM using vbox with lower spec configuration?
Definitely has something to do with a huge modlist, but that's hard to test. I could do testing in a VM, but honestly, that's way to much of a hassle.
I'll try replace REI with EMI and report again.
Definitely has something to do with a huge modlist, but that's hard to test. I could do testing in a VM, but honestly, that's way to much of a hassle.
I personally tested it with REI, both with a large modpack and small modpack but the significant performance drop is still there.
This noticeable performance drop even occurs when a couple of items of the mod are in a chest.
This ofcourse will be subjective to what specs someone is using so ill post mine for reference.
AMD Ryzen 5 1600
16GB RAM
AMD Radeon RX 6500 XT
First off: Try enabling caching itemstack in REI. Hover over settings > Display settings > caching item entry. This improves the performance significantly, but disables some effects
Okay, I finally had some time to do some testing. I know Forgero tools are not that efficient at rendering because they have to be constructed from data as opposed to loaded statically like every other Minecraft Item. But is also turns out that The Fabric Rendering API (FRAPI) also causes some slowdown. I dod some testing on my laptop where I was able so see some slowdown when viewing large pages with Forgero Items in REI. I tested some configurations to see where I could make some efficiency improvements.
Baseline: 25fps~
Baseline + remove a rendering mixin: 27fps~
Rendering nothing in place of a Forgero item: 34fps~
Guava cache: 29fps~
ConcurrentMap: 25fps~
What is really telling is the fact that the fps drops significantly even though I am not rendering anything at all, which leads me to believe that there is significant performance drawbacks to using FRAPI in the first place, but I kinda need to be able to render my items so that does not really help. I implemented some minor improvement using Guava's cache to help the situation. I'll be releasing it in the 0.9.4 update very soon. Unfortunately, it does not look like FRAPI is designed to work with rendering hundreds of custom models at the same time. I'll likely have to look at it some more, and maybe see if there is some optimization possible upstream in the Indigo library. I'll also have to look at optimization with caching for other situations, like the chest issue mentioned.
Thanks for taking the time to report the issue!
I have similiar mod that add item based on config and mod installed combination, it is Excavated Variant, they using are using Dynamic Asset Generator. I don't know if this information is useful but maybe can give an idea.
Yeah I am using a similar library, ARRP. But these libraries can't deal with rendering custom models based on ItemStack data. I'll see if I can create a native approach to rendering models myself. Maybe it will get native compatability with Sodium as well.
Solved by using a native rendering approach and not relying on FRAPI to render custom Item models. I had a sneaking suspicion FRAPI was causing performance issues when rendering large amount of models. Was able to also resolve all other graphical incompatibilities related to sodium as well. This will be resolved when #196 is released. Wasn't able to test if FRAPI was causing the issue before I created a native renering implementation, and the native approach destroys the old rendering by a mile. I was probably not using frapi right, but in my opinion, the native rendering is a lot simpler as well. I would like verify this from other people as well, but I suppose that would be hard given how old this issue is.