2057 replies to this topic

[WanWizard]

IIRC this driver update fixes it.

https://github.com/o...6794fb109874143
The issue you posted was fixed back in August after a lot of pestering Qviart to fix it.

 

EDIT: It was actually the update before that one, that fixed the skin issue.

 

It is not limited to Qviart, every HiSil box has the same issue with alphablending.

 

Qviart hasn't updated the BSP, in their words, "we send test drivers to OE-A so they can do the testing for us, we only update the BSP when drivers are stable".

 

And it isn't stable, in OE-A (I've tested it) it isn't fixed, it is worked around. Instead of seeing the UI build up like in OpenPLI, in ATV nothing happens at all for over a second, and then the completed UI is displayed. So the "fix" just holds FB updates until they are complete.

[Ev0]

 

IIRC this driver update fixes it.

https://github.com/o...6794fb109874143
The issue you posted was fixed back in August after a lot of pestering Qviart to fix it.

 

EDIT: It was actually the update before that one, that fixed the skin issue.

 

It is not limited to Qviart, every HiSil box has the same issue with alphablending.

 

And Qviart hasn't updated the BSP, in their words, "we send test drivers to OE-A so they can do the testing for us, we only update the BSP when drivers are stable".

 

Well I have tested Dual 4K, SF8008, Pulse4K, Multibox4K Pro, Sx88v2, H11s which are all HiSi boxes and none of them have the issue you have in PLi with this skin.

Edited by Ev0, 30 December 2023 - 13:07.

[WanWizard]

Question is do you want compatibility or not. In oe-a we can write to boxinfo and immediately that data is available to all running processes by SystemInfo. Your commit breaks a behaviour that is expected and that has been in force several years.

 

I agree with Littlesat that boxinfo should be immutable, since it was decided that enigma.info was the source of all truths. Updating boxinfo from within E2 is than absolutely not done, so maybe OE-A should implement this too to restore compatibiltiy.

 

This is a fix for one of the many flaws of the implementation, caused by OE-A's attitude to feedback from others. Which from the looks of it will block this improvement too.

 

And the eval is plain wrong because a string in enigma.info could match something in the namespace. It is lazy coding. And right now you don't seem to understand you are not in control of the contents of enigma.info.

I agree with you on this. Besides this, eval is considered evil in any programming language as it allows for execution of any arbitary code.

[WanWizard]

Well I have tested Dual 4K, SF8008, Pulse4K, Multibox4K Pro, Sx88v2, H11s which are all HiSi boxes and none of them have the issue you have in PLi with this skin.

 

Like I added, OE-A has just worked around it by holding FB updates until the drawing is complete.  It hasn't fixed the slow processing, it just doesn't show it.

 

Install this skin on ATV. Press OK to open the infobar. In OpenPLi it opens immediately and then you see it drawn and populated with data. In ATV, absolutely nothing happens for a second, then the complete infobar is shown.

In terms of time to completion, there is no difference between images, just OpenPLi shows the buildup, while ATV hides it. The slow buildup when using alphablending hasn't been fixed, otherwise you would see a significant speed difference (comparable to a BCM box).

[Ev0]

 

Well I have tested Dual 4K, SF8008, Pulse4K, Multibox4K Pro, Sx88v2, H11s which are all HiSi boxes and none of them have the issue you have in PLi with this skin.

 

Like I added, OE-A has just worked around it by holding FB updates until the drawing is complete.  It hasn't fixed the slow processing, it just doesn't show it.

 

Sorry I missed your edit.

Yes you are correct, AB is an issue with HiSi, i've not tried this skin on ATV, but on OpenBh when compared to Vu+, there is a slight delay in showing the infobar, but I would say it is around 0.5s, not 1+ seconds.

[WanWizard]

I didn't write there is a second time difference between HiSIl and BCM, I said the time to completion is about a second on the Dual 4K, both on ATV and on PLi.

 

My only point was that AB isn't fixed in OE-A, but the problem was hidden by delaying updating the FB so you don't see the effect.

[littlesat]

In the Netherlands we call this struisvogelpolitiek... 'ostrich politics' 

 

Here it does not always happen.... and I remember from years ago that at the time svgs came up it started and that was why I kept pngs on our standard skin. But I'm not 100% sure about this statement as it is too long ago.

Edited by littlesat, 30 December 2023 - 13:20.

[Ev0]

I didn't write there is a second time difference between HiSIl and BCM, I said the time to completion is about a second on the Dual 4K, both on ATV and on PLi.

 

My only point was that AB isn't fixed in OE-A, but the problem was hidden by delaying updating the FB so you don't see the effect.

I agree it is a workaround, but you have to decide which is better for the end user...

To have the infobar show instantly and then build in stages on the screen, or a slight delay before it appears complete.

The issue isn't just with this skin, it is every skin where AB is used.

[WanWizard]

The problem is caused by the size of the PNG's, the larger the image, the more visible the alphablend problem. Like Huevos mentioned, the root cause is most likely missing hardware accelleration for alpha blending.

[DimitarCC]

Well the problem of the infobar is that it uses 2 big png images with alphablending.

Maybe use images only in corners will fix the issue (like it is in second infobar)

[littlesat]

In this skin the stuff is as far I know SVGs.... and technically that is done for a good reason... but practically one of the requirements to use them is good hardware acceleration... especially with alpha blending... I hope this can be resolved.

Here in the UCLAN and Multibox (also HiSi) I do not experience it... 

 

 the root cause is most likely missing hardware accelleration for alpha blending.

[WanWizard]

I agree it is a workaround, but you have to decide which is better for the end user...

To have the infobar show instantly and then build in stages on the screen, or a slight delay before it appears complete.

The issue isn't just with this skin, it is every skin where AB is used.

True.

 

But I'd rather see something happening when I press a button, then press a button and nothing happens (so I press it again which can have nasty side effects). So from an end-user perspective, I don't like the work around.

 

I am a PHP developer, in web there is the same discussion, show the user the buildup of the page vs building the page and then slowing, every study shows most people like to see something happening, as waiting for something to happen always feels longer that it actually is.

[WanWizard]

Well the problem of the infobar is that it uses 2 big png images with alphablending.

Maybe use images only in corners will fix the issue (like it is in second infobar)

 

I think so, yes.

[littlesat]

Well the problem of the infobar is that it uses 2 big png images with alphablending.

Not it are pngs... could I overlooked something... Maybe indeed made them smaller... maybe directly on the required size?

[Ev0]

 

I agree it is a workaround, but you have to decide which is better for the end user...

To have the infobar show instantly and then build in stages on the screen, or a slight delay before it appears complete.

The issue isn't just with this skin, it is every skin where AB is used.

True.

 

But I'd rather see something happening when I press a button, then press a button and nothing happens (so I press it again which can have nasty side effects). So from an end-user perspective, I don't like the work around.

 

I am a PHP developer, in web there is the same discussion, show the user the buildup of the page vs building the page and then slowing, every study shows most people like to see something happening, as waiting for something to happen always feels longer that it actually is.

 

I take your point, however a slight delay to show the infobar complete (as said in obh this is approx 0.5s), compared to loading a complete webpage is a big difference.

For developers that use all different hw all the time, we notice these slight delays when testing.

*Most* end users, only have 1 or 2 boxes and it seems they usually stick to the same / similar brands, which means they are far less likely to notice a 0.5s delay as it will have always been like that for them.

Edited by Ev0, 30 December 2023 - 13:29.

[Huevos]

 

Question is do you want compatibility or not. In oe-a we can write to boxinfo and immediately that data is available to all running processes by SystemInfo. Your commit breaks a behaviour that is expected and that has been in force several years.

 

I agree with Littlesat that boxinfo should be immutable, since it was decided that enigma.info was the source of all truths. Updating boxinfo from within E2 is than absolutely not done, so maybe OE-A should implement this too to restore compatibiltiy.

 

This is a fix for one of the many flaws of the implementation, caused by OE-A's attitude to feedback from others. Which from the looks of it will block this improvement too.

 

And the eval is plain wrong because a string in enigma.info could match something in the namespace. It is lazy coding. And right now you don't seem to understand you are not in control of the contents of enigma.info.

I agree with you on this. Besides this, eval is considered evil in any programming language as it allows for execution of any arbitary code.

 

The data in enigma.info is immutable when loaded into BoxInfo. What Littlesat has broken is something different. He has disabled the ability for BoxInfo to write to SystemInfo. The whole point of BoxInfo is compatibility. If you are going to change the rules now you will not have compatibility with oe-a and third party plugins that are using this feature.

[WanWizard]

I can only speak out of personal experience, the delay is long enough for me to doubt the box has seen the keypress (most HiSil boxes have notouriously bad AB's or IR receptors) and press the key again.

[DimitarCC]

Well the problem of the infobar is that it uses 2 big png images with alphablending.

Not it are pngs... could I overlooked something... Maybe indeed made them smaller... maybe directly on the required size?

They are on correct size. But the width is almost 1900px.so rendering such a big picture with AB choking HiSilicon boxes.

[WanWizard]

The data in enigma.info is immutable when loaded into BoxInfo. What Littlesat has broken is something different. He has disabled the ability for BoxInfo to write to SystemInfo. The whole point of BoxInfo is compatibility. If you are going to change the rules now you will not have compatibility with oe-a and third party plugins that are using this feature.

 

What is the point of saying "the source is immutable" (which is itsn't, it is a mutable text file, in that respect the first device driver idea was better), but then make the container reading it, which is used as the source of truth in E2, mutable, and explicitly say it is a feature?

 

There is NO valid reason for any bit of E2 code to need to alter the truth about the hardware, if you allow that, you have just dumped the entire idea about WHY an immutable boxinfo was needed.

 

This sounds very much like the continuous story of OE-A: A good idea, ignoring input from others, then completely make a bodge job of the implementation due to a failure of understanding what it was about.

[Ev0]

I can only speak out of personal experience, the delay is long enough for me to doubt the box has seen the keypress (most HiSil boxes have notouriously bad AB's or IR receptors) and press the key again.

Yes I understand what you are saying (I have done it myself), but I use the Ultimo4K as my main box, all day everyday, so when using HiSi the slight delay is noticable.

However if I stop using the Ultimo4K for a day or 2, and use only a HiSi box (which I have done a few times in the last couple of years), you soon stop noticing the delay and it becomes "normal".

Then when I go back to using the Ultimo4K again, I notice it's much more responsive again.

But as said, most end users, they only have 1 or 2 boxes to use and usually they have the same chipset, so after the 1st day they will never notice the delay again.