We are facing problems with oxygene performance in Visual Studio 2019. We sent our solution and video with example to marc in February. I am opening this topic for better monitoring.
I ask you to pay attention to this point, as the actual performance actually makes use unviable. we are willing to collaborate in whatever it takes to help identify what causes it.
To simulate it, just open our project and edit some sample files
Thanx for opening a new thread so we can work on this. my colleague @viktoriad is looking at the issue now, and will get back to you once she knows more. I’m hoping we can have this fixed soon.
We’ve isolated the problem. A full proper fix will take a few days, but with the next build (I can send you one later, but also with tomorrow’s build) you can add the following registry key to temporarily disable the drop-down boxes at the top of the editor; populating them, combined with the huge size of the project, is what us causing the delay.
the key itself should already exist (in 64-bit windows it will be “Software\WOW64\RemObjects\Elements”) and should contain other values, such s “Oxygene”=“1” already. the new value should be a of type string.
hopefully we’ll have a proper fix for next week’s build, or sometime during the next week.
Hmm, let me check with Vika. i’m pretty sure you’re supposd to need the setting. But either way, if the combos are disabled that’s good and should allow you to test if the performance issues are either (a) better or (b) completely fixed with this.
we could see an improvement in performance when the combos are not refilled.
however we still have problems, example when editing forms (uprogramacaocarga), when we edit sometimes the visual studio closes.
another point is the memory consumption see the print. it is common for visual studio to pass 3GB and ebuild to pass 4.5gb
