Using scaleX/scaleY instead of alpha/visible to control visibility performs better

[hiratariq]

Hi,

In a very complex render tree, I experimented with scaling the components down to nothing instead of hiding their visibility,
link to example

It seems to me that scaleX/scaleY is significantly faster than alpha/visible to mainly hide and show. It makes quite a difference on our slower device as well. I haven't come across any penalty from Lightning that comes with it, that is, patching is faster comparatively, and the drawFrame right after seems to take about the same amount of time.

Is there something I am overlooking, if not, why is scaling faster than visibility?

Thanks!

[imtiaz101325]

This is interesting! Which devices specifically did you try this on? @hiratariq
Did you also check FPS and memory usage?

[hiratariq]

The device is a STB, FPS generally is pretty down on it anyway, same with memory usage.

[imtiaz101325]

@hiratariq is your STB running RDK software like RDK-V?
If not could you share the browser the STB uses?

[hiratariq]

It's not running RDK.
Browser is Chrome 39. To make our code work on it we transpile it using babel.
We limit memory pressure to 3.8e6 of GPU memory usage in pixels for the device during lightning stage initialisation.

However the scale vs visibility performance comparison is not just limited to this device, its just more noticeable on the device as it is quite slow.

[imtiaz101325]

Hi @hiratariq

I am not seeing the performance benefits on my machine(M1 Mac).

I copied your code here.

Attaching the profile in case you wanna check the difference on your end:
scaleIsMorePerfPOC_profile.json.zip

Maybe you could try to capture the performance profile on your end and share?

[hiratariq]

Edit: Please ignore this comment

Hi @imtiaz101325 apologies I've taken this long to check for updates on github.

I think at the time I posted the codepen I forgot to disable image worker. But I've updated it to not use it. In my codebase I completely removed alpha/visible property and used scale throughout which made significant difference on the STB.

In the codepen however, at the time I posted it here I saw the difference I was talking about, but rerunning today the results are inconsistent and changing order of the lines of code also effects the time. I'll have to write an elaborate example instead. I've tweaked the codepen a little which basically after showing and hiding the Element I repeat it again. So previously I had
hide (alpha),
show (alpha),
hide (scale),
show (scale)

Now I have
hide (alpha),
show (alpha),
hide again (alpha),
show again (alpha),
hide (scale),
show (scale),
hide again (scale),
show again (scale),

But really changing the order of lines changes everything and the codepen doesn't do a good enough job to prove my findings in the actual codebase I am working with.

I'll give the code you've attached a go and get back to you with better example.

[hiratariq]

Edit: Please ignore the striked through bit

These are screenshots from my profiling session. But I have gone above and beyond to prove this in isolation and timing the execution of the two methods in my codebase. It turns out it is only an issue when I am running the debugger. So this really isn't an issue and can be closed. Apologies for the confusion.

[hiratariq]

Apologies, but after having slept on the issue I realised patching without rendering anything was the missing piece in the codePen so I have now updated it https://codepen.io/hiratariq/pen/wvErXmb

Now it does show that scaling instead of changing visibility does perform better, so the issue is valid thats why reopened.

[imtiaz101325]

Hi @hiratariq
The results are indeed interesting. I have quickly set it up and observed the results.

Will look into this further and update here and on my public workbook https://imtiaz101325.notion.site/Investigation-rdkcentral-Lightning-issues-466-1a98a0de12374ad88c6f39eab4912e04