Fix #2937: Improve performance of tocolor

[TracerDS]

Fixes #2937:
Moved tocolor into an embedded section. That way it should be faster...?

[xLive]

Did you perform any benchmarks? The assert and range checks will make it significantly slower than the C++ implementation.

[TracerDS]

Did you perform any benchmarks? The assert and range checks will make it significantly slower than the C++ implementation.

Unfortunatelly I did not. Didnt have the chance.
In that case a simple if statement may be used instead

[ArranTuna]

crun t1 = getTickCount() for i=1, 1000000 do tocolor(1, 2, 3, 4) end t2 = getTickCount() outputChatBox(t2-t1)
254

I then added your lua version of tocolor into runcode and it took 444 ms so this proves that this does NOT increase performance and actually degrades performance? As well as the fact that if you have 500 resources, each lua VM has a copy of this tocolor, so it's just unnecessarily increasing memory usage of every resource.

[TracerDS]

crun t1 = getTickCount() for i=1, 1000000 do tocolor(1, 2, 3, 4) end t2 = getTickCount() outputChatBox(t2-t1) 254

I then added your lua version of tocolor into runcode and it took 444 ms so this proves that this does NOT increase performance and actually degrades performance?

Hmm, it looks like type() function is significantly slowing everything. But without that an error might occur 🤔

As well as the fact that if you have 500 resources, each lua VM has a copy of this tocolor, so it's just unnecessarily increasing memory usage of every resource.

This is not a significant increase in memory, if any

[thisdp]

crun t1 = getTickCount() for i=1, 1000000 do tocolor(1, 2, 3, 4) end t2 = getTickCount() outputChatBox(t2-t1) 254
I then added your lua version of tocolor into runcode and it took 444 ms so this proves that this does NOT increase performance and actually degrades performance?

Hmm, it looks like type() function is significantly slowing everything. But without that an error might occur 🤔

As well as the fact that if you have 500 resources, each lua VM has a copy of this tocolor, so it's just unnecessarily increasing memory usage of every resource.

This is not a significant increase in memory, if any

It's nothing about type(). The main reason is function call in lua is extremely slow. That's why i said lua implemented tocolor will decrease performance.

And another problem, your code can not work if r g b a are float like 128.5

[CrosRoad95]

maybe we should focus on fixing "core issue" - you use "tocolor" because "dxDraw" functions need to be called every frame, what if, we design some "widget system" where you declare it, example rectangle, set color once and mta automatically drawing it?

local rect = dxCreateRectangleWidget(100, 100, 100, 100, tocolor(255, 0, 0)) -- no "onClientRender" required

it will be equivalent of onClientRender + dxDrawRectangle every frame
with functions such a: change position, size, color ect

[thisdp]

maybe we should focus on fixing "core issue" - you use "tocolor" because "dxDraw" functions need to be called every frame, what if, we design some "widget system" where you declare it, example rectangle, set color once and mta automatically drawing it?

local rect = dxCreateRectangleWidget(100, 100, 100, 100, tocolor(255, 0, 0)) -- no "onClientRender" required

it will be equivalent of onClientRender + dxDrawRectangle every frame with functions such a: change position, size, color ect

btw, tocolor is faster enough, dx functions are far more slower

[thisdp]

maybe we should focus on fixing "core issue" - you use "tocolor" because "dxDraw" functions need to be called every frame, what if, we design some "widget system" where you declare it, example rectangle, set color once and mta automatically drawing it?

local rect = dxCreateRectangleWidget(100, 100, 100, 100, tocolor(255, 0, 0)) -- no "onClientRender" required

it will be equivalent of onClientRender + dxDrawRectangle every frame with functions such a: change position, size, color ect

maybe also need a
dxSetRectangleWidgetConfig(widget,100, 100, 100, 100, tocolor(255, 0, 0))

widget is a number instead of element

[ArranTuna]

There's actually a really simple fix for this which I already use except in the few cases where the color frequently changes instead of:

dxDrawText(blah, tocolor(255, 255, 255, 255), blah)

You just add this at top of script:

local white = tocolor(255, 255, 255, 255)

Then:

dxDrawText(blah, white, blah)

[Pirulax]

or, just learn to use hex instead of tocolor?

tocolor(255, 255, 255, 255) == 0xFFFFFFFF

The hex format is 0xAARRGGBB
FF is 255, 7F would be 127, and so on.. You'll learn it the more you use it.

[thisdp]

or, just learn to use hex instead of tocolor?

tocolor(255, 255, 255, 255) == 0xFFFFFFFF

The hex format is 0xAARRGGBB FF is 255, 7F would be 127, and so on.. You'll learn it the more you use it.

Best way to increase performance of tocolor (Deprecate tocolor) :merow:

[dmi7ry]

The hex format is 0xAARRGGBB FF is 255, 7F would be 127, and so on.. You'll learn it the more you use it.

But things get noticeably worse when you need to change individual components dynamically. Native implementation is better for such cases.

[TracerDS]

Im not interested in advancing this PR further anymore.
If someone wants to refresh it, feel free to do so.