I can't see that a simple one-shot property change would cause any lag, even when done on a lot of vb objects. But for example, maybe you're trying to do more intense gfx stuff - and you're doing it way too "smoothly"? LUA is a scripting language, after all. As an example: if I wanted to fade the color on a lot of buttons simultaneously and noticed it was lagging, an idle timer could be used to make sure fades were done as smooth as possible, without lagging the whole GUI.
So far, I've found that the Lua API is "fast enough" in almost any case if you do things the right way.
PS. About the texture issue, I've noticed that vb is a bit slow when it comes to dealing with larger bitmap images (vb:bitmap). Maybe it's related. I used bitmaps as background for piano roll stripes, and rebuilding these objects when scrolling was way too heavy, so I had to resort to using rack styles for these stripes.
I can comment on my exact experience with this matter (taking as starting a CPU i7 and a mid-range graphics card, quite powerful and a big window tool with multiple objects):
- (with textures = none ) Modifying a specific property (one color) to multiple objects (> 1000) is very fast (almost instantaneous). The LUA code, using massive iterations, goes very very fast. You are only modifying the color, by pressing a simple button to execute the function in charge of doing it. This works reasonably well.
- (with textures = none ) If instead of using a button to execute the function for modify the colors, you use a slider, you not only modify the color, but you are also moving a slider graphically. Here, slight lags can be presented in the GUI.
- (with textures = default or other). I have verified that the use of textures in Renoise preferences drastically influence when doing something that involves changing the size of objects. Modify the size of a Rack, modify the size of a button, or whatever, in a specific scenario, defined in a very large window with a multitude of objects (hundreds of buttons). Apparently, textures should be resized each time you modify some dimension (use remove_child of a rack, or visible = false, or modify the size of multiple buttons by massive iteration). A rack has its own texture. A button has its own texture, any object has an associated texture (BMP image), which must be resized. It seems that resizing these textures is a bit heavy, when it should be more fluid (I think). The LUA code goes very very fast. But if you use a thema with the textures enabled, you may have a notorious lag problem in tools with very large windows, with many objects.
If you build tools with small windows, with few objects to modify, you will not notice lag in most cases. I suspect that the resizing of the textures generates lags, it does not work fast, it is much slower than the execution speed of the LUA code, and it will be noticed in the heaviest cases (large windows with hundreds of small objects, each with its texture)).
- Lua time code |----------------> done!
- textures time ¿to resize? |--------------------------------------------------------------------------------------------------------------------> done! = graphic lag
It would be nice if Danoise confirmed this. And I have used a 10 ms timer to delay the resizing of a wraparound rack, when you hide (visible = false) another internal rack, and you can get an apparently lower lag behavior. But a programmer should not be playing with strange timers to adjust graphical behaviors.
I have reached the point that it is necessary to disable the textures (Textures = none). If you want to control a large and dynamic window (resizable size objects), if you disabling the textures, the tool goes like a bullet.
This also makes me think that Renoise can present notorious graphics problems in very large windows (2K or 4K monitors) if you have the textures enabled. If you have used Renoise in a 4k and have strange behavior in the graphics, try to disable the textures, simply.
If in the future Taktik wants to improve the Renoise GUI, or improve the load of the textures, or simply delete them and bet on vector images, even if the final aspect is more flat. I do not know what would be the easiest solution, but it seems clear that the textures (BMP images that are resized) are an important graphic ballast.
If you want to do tests... Build a one-button class. Iterating, build a window of HD size (~1920x1080 px) with several panels and inside place the same buttons (>1000 for example), to be able to modify its size, or color, using a shutter button, a slider ... Try to use it with textures or disabling the textures, and compare. The difference of the graphical performance is notorious.
I point out all this, because I myself have fallen into the error of blaming the LUA code for "slow", when the problem is directly related to the loading / resizing of the textures. Obviously, if you use a static window, you will not notice anything in many cases, because you are not modifying any dimension, nor dragging any object from its place.
I do not know exactly what is the cause. But I know it has to do directly with the textures that Renoise uses:
- Configure the textures: Renoise... Preferences/Theme: Textures = None (or Default...)
- Any type of texture (Default or Dotted or Eddged or Jeans or Metal) will work the same (same performance). All are formed by the same number and dimensions of BMP images. And it does not matter if you redimension these images. The graphic performance will be the same.
- Root folder of textures (Windows): C:\Program Files\Renoise 3.1.1\Resources\Skin\Textures
Edited by Raul (ulneiz), 22 March 2018 - 12:46.