2057 replies to this topic

[Huevos]

And there is indeed something obvious here as you can see it building-up.... But this is not always the fact....Something I do not see in our current skin... I'm afraid this is because of the svg files.... so I'm afraid we can better revert to png.

Littlesat can you explain the problem with svg or show a screengrab.

[Huevos]

@Hueovos, the widget has the same name and the order of the picons is also the same...

Good.   As long as the widget works universally it  doesn't matter if there are differences in the python code between distros. 

[DimitarCC]

And there is indeed something obvious here as you can see it building-up.... But this is not always the fact....Something I do not see in our current skin... I'm afraid this is because of the svg files.... so I'm afraid we can better revert to png.

 

reverting to png is not good idea since scaling is crap and sometimes it really breaks the quality. So i suggest rater fix the svg rendering on PLi....On Vix i have no issues with svgs.

[WanWizard]

There are some weird things going on with the rendering.

 

Why for example can you easily see the buildup of the info bar, but other screens like the channel list are displayed instantaneously?

 

OE-A based images have the same underlying issue, but there it isn't visible because the screen isn't shown until built.

In OpenPLi when you press OK you see the infobar being constructed, in ATV you see nothing for a second, and then the infobar is shown complete. I timed it, there is no time difference between the two images.

 

So the question is, why does the infobar render so slowly, compared to the other screens, some with a lot more information?

[Huevos]

First or second infobar?

 

Is this on a box with a HiSi processor?

Edited by Huevos, 28 November 2023 - 13:39.

[WanWizard]

A picture says more than 1000 words: https://www.veed.io/...bf5?panel=share

 

You can clearly see the light-grey background of the infobar being built up line by line, like it is rolled down,

 

This is on a HiSilicon box.

[DimitarCC]

Well on vu+ no such issues. I guess is a problem on HiSilicon based boxes....
And that gray area is normal png.

 

Maybe you can try to make images with alphatest="on" instead of "blend".

 

I guess HiSilicon boxes have problems rendering transparency with blend.

Edited by DimitarCC, 28 November 2023 - 13:59.

[littlesat]

.On Vix i have no issues with svgs.

 

It seems on OpenATV they have the same issue.Wanwizard posted a snapshot previously. On OpenPLi we have the same (but I cannot show you as by coding is now kind of rubish).

 

The slow building is likely related to the svg... for relative small icons they are even not helpful at all.... it sounds nice of course because these vector based icons can be enlarged, but they really do not save space and most time this scaling is not needed at all.... and it slow stuff down. I'm afraid that is the reason why it looks sometimes that slowly. I remember this was one of the pain topics when they were introduced... because initially I liked them for the same reason you explain to me they are a mist, but afterwards they 'hurt'.

Edited by littlesat, 28 November 2023 - 14:11.

[WanWizard]

Possible, but something that needs fixing, either on the skin side or on the E2 side.

 

Because the workaround that OE-A seems to have implemented doesn't work either ( I think I prefer to see it being built then nothing happening for over a second until the entire infobar is displayed ).

 

But for that we first need to know what the root cause of this issue is.

 

It is not an svg issue ( you say it is a png ), and it only happens with the infobar, not will other screens. With FullNightHD you can also see png's being painted, for example in the GMEPG and the V-keyboard, but those png's are a lot smaller.

[WanWizard]

It seems on OpenATV they have the same issue.Wanwizard posted a snapshot previously. On OpenPLi we have the same (but I cannot show you as by coding is now kind of rubish).

 

According to Dimitar, the infobar background is a png, not an svg.

 

ATV doesn't show the rendering, they seem to render in a buffer, then display the buffer. Which has the effect of nothing happening for a second, then the infobar is shown in its final state.

 

Both have the same built-up issue. only in OpenPLi it is visible and in ATV not. Time until the infobar is displayed is identical with both images.

[littlesat]

Maybe you can try to make images with alphatest="on" instead of "blend".

Also a good point... this is also most likely a performance 'killer'.

[littlesat]

According to Dimitar, the infobar background is a png, not an svg.

->

Yes I know.... then it looks like we change the alfa test I'm afraid....

[Huevos]

A picture says more than 1000 words: https://www.veed.io/...bf5?panel=share

 

You can clearly see the light-grey background of the infobar being built up line by line, like it is rolled down,

 

This is on a HiSilicon box.

HiSi boxes have major rendering problems which is why we need all those silly workarounds in configure.ac. Don't even seem to be capable of alpha blending.

[littlesat]

Now I changed all the alphatest="blend" to alphatest="on" and as far I can see visible there is no change.... and until now it is not slow anymore.

[Huevos]

 

Maybe you can try to make images with alphatest="on" instead of "blend".

 

Also a good point... this is also most likely a performance 'killer'.

 

That is a horrible solution. On decent boxes there is zero performance hit and the images render properly. with alphatest="on" you get a terrible halo. Even worse if something changes below the graphic.

[DimitarCC]

According to Dimitar, the infobar background is a png, not an svg.

->

Yes I know.... then it looks like we change the alfa test I'm afraid....

 

No! Changing alphatest will break images with rounded corners. That will kill the look of the skin. I will not agree to that.

 

On Vu+ there is zero slowdown. I dont think we should break the skin because HiSilicon have crappy rendering...

Edited by DimitarCC, 28 November 2023 - 14:20.

[littlesat]

@DimitarCC,

 

here one of my PVR state tests..... based on this I still think we can put the picon in the gray part and add something extra's for the PVRState on the screen..... This also helps for e.g. Timeshift screens.

 

 

 PVRStatetest.jpg   64.31KB   0 downloads

 

my testcode PVRState screen:

  <!-- PVR State -->
  <screen name="PVRState" position="100,100" size="500,500" backgroundColor="black" zPosition="5" flags="wfNoBorder">
  <widget name="statusicon" position="160,160" zPosition="3" size="100,100" pixmaps="icons/pvr/play.svg,icons/pvr/pause.svg,icons/pvr/stop.svg,icons/pvr/ff.svg,icons/pvr/rew.svg,icons/pvr/slow.svg" alphatest="on"/>
<widget name="speed" foregroundColor="white" halign="left" position="260,160" size="90,45" font="Bold; 40" transparent="1"/>
    <widget name="state" position="0,400" size="225,90" backgroundColor="background5" borderWidth="2" font="Regular;84" borderColor="black" halign="center" alphatest="on"/>
  </screen>

Edited by littlesat, 28 November 2023 - 14:20.

[DimitarCC]

P.S. If you do it in the python depending on the box model to relay blend -> on... then OK. But i dont think the skin have to look shitty on Vu+ where it works just fine.

 

P.S.2 alphatest doesnt matter for svgs since they doesnt have alpha transparency usually

Edited by DimitarCC, 28 November 2023 - 14:24.

[littlesat]

No! Changing alphatest will break images with rounded corners. That will kill the look of the skin. I will not agree to that.

->

I do not see that here.... maybe this should be arranged on box time so blend is replaced by on for boxes that accepted it...

 

But which boxes go wierd here....? Sounds like we need to a a feature in systeminfo.py ["BlandingRequired"] or something like that..... and then when rendering the skin catch this attribute and replace it when needed.

 

Looks like some hardware accelerators do 'hurt' us here....

Edited by littlesat, 28 November 2023 - 14:26.

[DimitarCC]

All HISilicon based boxes have problems with alphablending for sure. And some cheap broadcom boxes too...

 

I think making it to relay blend -> on for unsupported boxes is the best solution.