PDA

View Full Version : [Zgemma H7] picon caching strangeness



BrokenUnusableAccount
15-03-22, 17:19
Note: My Zgemma H7 is set to always output 1080P (to match my HD TV) no matter what the resolution of any video that it may be playing, and I use a 1080 skin.

For a long time, the perfectionist in me has been irritated by the fact that picons display with an inconsistent quality.
Sometimes with obvious jagged edges and steps visible, other times looking 100% perfect.

I think what's happening is that the pixmap caching is caching the picons read from their files after they have been scaled ready to be displayed, and this results in the large picons displayed in, for example, the InfoBar sometimes being upscaled from low resolution versions that were cached when small picons were displayed in, for example, the grid EPG or the movie list.

At present, I'm fixing this by using this modified version of /usr/lib/enigma2/python/Tools/LoadPixmap.py

my file: https://github.com/BrianG61UK/enigma2/blob/PixmapCaching/lib/python/Tools/LoadPixmap.py

compared: https://github.com/BrianG61UK/enigma2/commit/4b654b2d665c0871806c6e263f09f0db60025ff8
on my box.

It's not obvious why it works, and the fact that it does suggest that at some point caching was deliberately not asked for when displaying picons.

However, it doesn't seem to noticeably slow things down on my box, but is it an acceptable solution for me to do a pull request?

It does still allow code to ask for caching in cases where it is likely to help things go at acceptable speed, like if the same pixmap is used a large number of times on the same screen (perhaps parts of the grid EPG might do this, I don't know?).
But it also does probably result in less caching occurring, and thus more reading pixmaps from files.

Should I make a pull request, or should I try and have a go at, perhaps, making the pixmap caching in some way bitmap size aware?

BrokenUnusableAccount
16-03-22, 14:29
Nobody else notices inconsistent rendering of picons?

Perhaps almost nobody besides me enables picon display in multiple places so that different sized picons are displayed during their use OpenViX?

twol
16-03-22, 14:46
Nobody else notices inconsistent rendering of picons?

Perhaps almost nobody besides me enables picon display in multiple places so that different sized picons are displayed during their use OpenViX?

I only use them in infobar, and haven't changed my picons in years. Just briefly turned them on in the EPG and have to say not great, but really cannot remember if they have ever looked better

Joe_90
16-03-22, 15:26
Nobody else notices inconsistent rendering of picons?

Perhaps almost nobody besides me enables picon display in multiple places so that different sized picons are displayed during their use OpenViX?

I use them in channel list and infobar on 1080 TV and 1080 skin. Can't say that I have particularly noticed any jaggies and I don't recall any user reports of inconsistencies in picon presentation.

spanner123
16-03-22, 17:56
I'm using the simple 1080 skin on my solo2 and picons display fine in all scenarios. What picons are you using? I use the one from plugins snp-full 220x132 light on transparent.

birdman
16-03-22, 20:30
Nobody else notices inconsistent rendering of picons?No.
If I go to the graphical EPG, get to a channel that I haven't seen since boot-up (so its picon is displayed on the left hand side - small) and select it, the Infobar that then comes up has a much larger version of the picon, and it looks fine to me.

Huevos
16-03-22, 21:38
Brian I don't get what you are saying.

SVG the resolution is cached. If you open the same SVG at a different resolution the cache will hold both.

With the PNGs they are loaded at their native resolution.

Huevos
16-03-22, 21:51
No.
If I go to the graphical EPG, get to a channel that I haven't seen since boot-up (so its picon is displayed on the left hand side - small) and select it, the Infobar that then comes up has a much larger version of the picon, and it looks fine to me.The picon is scaled in epixmap.cpp so it fits the containing element. The flag is set here: https://github.com/OpenViX/enigma2/blob/Developer/lib/python/Components/Renderer/Picon.py#L146

The question was, is the scaling being done on a picon that was already loaded at a lower resolution than native, making it look jagged at the larger size.

BrokenUnusableAccount
16-03-22, 22:37
More info:
I'm using these icons: enigma2-plugin-picons-snp-full.220x132-190x102.light.on.transparent_2022-03-04--23-13-14_all.ipk
I mostly use the "Simple Ten Eighty" skin, though I did try a couple of other 1080 skins and I seemed to see the same inconsistant picon display.

BrokenUnusableAccount
16-03-22, 22:40
The question was, is the scaling being done on a picon that was already loaded at a lower resolution than native, making it look jagged at the larger size.
That's exactly what I think is happening.

birdman
17-03-22, 03:31
The question was, is the scaling being done on a picon that was already loaded at a lower resolution than native, making it look jagged at the larger size.Which is why I gave an example where my first view of it was as a small image, followed by seeing the same picon at a larger size (~ 4 times linearly?).

Huevos
17-03-22, 10:50
If I had to guess I would say this is maybe a HiSi bug.

Joe_90
17-03-22, 12:18
I flashed dev 6.1 on my AX61 HD and installed the same snp picons as in post #9 above. Using Simple 1080 skin, I displayed the picons on the channel list initially, followed by the larger picon image in the infobar. All looks ok - no jaggies.

ccs
17-03-22, 13:19
I've never understood the need for picons, so maybe I shouldn't comment. 6.0.008 (Release) Same picons as above.

ET10K/Large - clean picon image, after enlarging a snapshot.

63477



ET10K/Small - slightly jagged, after enlarging a snapshot.

Ultimo4K/Large - slightly jagged, after enlarging a snapshot.:confused:

Ultimo4K/Small - slightly jagged, after enlarging a snapshot.

All 3 look much like this...

63478

I've tried a different channel and the same applies.

Huevos
17-03-22, 15:35
Where are you setting large/small?

ccs
17-03-22, 15:56
Where are you setting large/small?

I selected a channel number after a gui restart to get a "large" picon in the infobar.

I selected a channel from the grid epg (picons showing) after a gui restart to cache a "small" picon which I assume is resized to "large" in the infobar.

BrokenUnusableAccount
17-03-22, 16:16
Two good picons to show the effect are "CNBC HD" (when distorted the bottom letters look flattened against the floor) and "NTD" (good example of a picon with large slanted lines, steps show when distorted).

Huevos
17-03-22, 16:49
I selected a channel number after a gui restart to get a "large" picon in the infobar.

I selected a channel from the grid epg (picons showing) after a gui restart to cache a "small" picon which I assume is resized to "large" in the infobar.

:confused: Are they PNG?

loadPNG() has no scale argument. The files are cached at native resolution. Any resizing of the graphic would be done when attaching it to the lower layer.

https://github.com/OpenViX/enigma2/blob/Developer/lib/gdi/epng.cpp#L19

Huevos
17-03-22, 16:50
Two good picons to show the effect are "CNBC HD" (when distorted the bottom letters look flattened against the floor) and "NTD" (good example of a picon with large slanted lines, steps show when distorted).Brian you need to look at adding some SVG picons.

ccs
17-03-22, 16:54
:confused: Are they PNG?

loadPNG() has no scale argument. The files are cached at native resolution. Any resizing of the graphic would be done when attaching it to the lower layer.

https://github.com/OpenViX/enigma2/blob/Developer/lib/gdi/epng.cpp#L19

I'm just following on from here.....


More info:
I'm using these icons: enigma2-plugin-picons-snp-full.220x132-190x102.light.on.transparent_2022-03-04--23-13-14_all.ipk
I mostly use the "Simple Ten Eighty" skin, though I did try a couple of other 1080 skins and I seemed to see the same inconsistant picon display.

BrokenUnusableAccount
17-03-22, 16:58
bad:63479


good:63480


bad:63481


good:63482


bad:63483


good:63484


All captured from the first infobar, the one that temporarily appears over the bottom of the screen when you press OK once while viewing.

BrokenUnusableAccount
17-03-22, 17:00
Brian you need to look at adding some SVG picons.

Yes. That's a good* idea. Spend months recrafting all the icons that are only available in PNG as custom built SVG files rather than fixing a coding bug.

*or do I mean bad

Joe_90
17-03-22, 17:48
How big is your TV screen Brian! The differences between those picons would be difficult to spot on a 1080 tv screen at usual viewing distance. Or maybe, it's my old eyesight...:cool:

ccs
17-03-22, 18:00
How big is your TV screen Brian! The differences between those picons would be difficult to spot on a 1080 tv screen at usual viewing distance. Or maybe, it's my old eyesight...:cool:

That's what I thought, I can't see any difference at all.

BrokenUnusableAccount
17-03-22, 19:42
How big is your TV screen Brian! The differences between those picons would be difficult to spot on a 1080 tv screen at usual viewing distance. Or maybe, it's my old eyesight...:cool:

32 inch. Not big at all by modern standards.

Yes, at normal viewing distance there isn't much difference, but that's not really a reason not to figure out what's wrong and fix it.
You are sometimes going to be closer to the screen.
Maybe it isn't the caching that's doing it, but after a restart bringing up the small icon in the EPG first and then displaying the big one on the first infobar seems to be what triggers it.

Huevos
17-03-22, 21:46
Yes. That's a good* idea. Spend months recrafting all the icons that are only available in PNG as custom built SVG files rather than fixing a coding bug.

*or do I mean bad

The picons on the feeds are built from SVG.

BrokenUnusableAccount
17-03-22, 22:07
The picons on the feeds are built from SVG.

What picons on the feeds?
How do I get them?

When you say built from SVG are you actually saying they consist entirely of SVG files?
Or are you just pointlessly pointing out that the picons PNG files were, or may have been from converted SVG files?

You need to exlain what you're actually trying to say, badly scaling a PNG that came from an SVG file messes it up just as much (or worse) than scaling a PNG that was made as a PNG.

BrokenUnusableAccount
17-03-22, 22:14
That's what I thought, I can't see any difference at all.

You don't sit near your computer so you can read the text on it's screen?

That's daft.

Stop trying to cancel by bugs.

ccs
17-03-22, 22:18
You don't sit near your computer so you can read the text on it's screen?

That's daft.

I was referring to picons looking the same on the tv, jagged or not.

Anyway, picons now removed for ever more, horrendous springs to mind, imho.

ccs
17-03-22, 22:21
Stop trying to cancel by bugs. ........ :)

BrokenUnusableAccount
17-03-22, 22:33
It'll just have to be yet another of my little patches I do after I update or flash a new version of OpenViX.

They make it so much better but seem to get argued against and insulted if I even suggest making them part of OpenViX.

Huevos
17-03-22, 23:26
What picons on the feeds?
How do I get them?

When you say built from SVG are you actually saying they consist entirely of SVG files?
Or are you just pointlessly pointing out that the picons PNG files were, or may have been from converted SVG files?

You need to exlain what you're actually trying to say, badly scaling a PNG that came from an SVG file messes it up just as much (or worse) than scaling a PNG that was made as a PNG.The picon sets are built to PNG but no reason why you couldn't use the SVGs directly.
https://github.com/picons/

BrokenUnusableAccount
18-03-22, 00:05
The picon sets are built to PNG but no reason why you couldn't use the SVGs directly.
https://github.com/picons/

No. Those are built from a mixture of PNGs and SVGs.

There are a lot of picons where no SVG could be found on the internet only a PNG, so they use the PNG.
If I remember right they even have instructions telling you what range of sizes they prefer for the PNG when you submit a new picon and can't provide a SVG.

BrokenUnusableAccount
18-03-22, 01:43
--deleted--

BrokenUnusableAccount
21-03-22, 04:26
At present, I'm fixing this by using this modified version of /usr/lib/enigma2/python/Tools/LoadPixmap.py

my file: https://github.com/BrianG61UK/enigma2/blob/PixmapCaching/lib/python/Tools/LoadPixmap.py

compared: https://github.com/BrianG61UK/enigma2/commit/4b654b2d665c0871806c6e263f09f0db60025ff8
on my box.

Actually it doesn't quite seem to fix all cases.
I have changed to a version of LoadPixmap.py that completely disables caching in all cases.
Everything still goes at more than acceptable speed on my Zgemma H7.

BrokenUnusableAccount
21-03-22, 19:52
If I had to guess I would say this is maybe a HiSi bug.
No it's all this code written with comments that mostly just explain what the following (not at all difficult to understand) line of code does rather than explaining how everything is supposed to work together or what and when a function is intended to be used for.
Oh and by the way I reported the bug and my box isn't based on HiSi silicon.

BrokenUnusableAccount
29-03-22, 22:30
Brian you need to look at adding some SVG picons.
As far as I can see the command line tools to automate converting from the available SVGs of the logos into SVGs with correctly set viewports to make them display correctly in OpenViX simply don't exist and doing it manually actually produces a worse result than what have now, at least if you do in the most obvious way.