86 replies to this topic

[maigais]

or you do not Picone smaller in size!!!!!!

Edited by maigais, 1 August 2013 - 07:37.

[littlesat]

The picons are autoscaling.... And the aspect ratio should be keeping in tact. This looks like the space it fills is filled with something strange....

[maigais]

now it looks like that there Picone be 80x60 in size
instead of 100x60
That's why I asked

[littlesat]

They are scaled to fit with keeping the aspect ratio... just like the Graphical Mutly EPG does... In this case as far I know they are in standard downscaled to 26 high and 52 wide....

 

And it seems the Solo2 drivers possibly cannot handle the blackfill that should be transparant...

Edited by littlesat, 1 August 2013 - 07:56.

[MiLo]

It appears that the remaining space is filled with "transparent" data.

If the skin attempts to blend this, and your hardware supports alpha blending (only the ET boxes, a.f.i.k.) this can be blended with the underlying UI components. Otherwise, it will drill a hole through the UI and you'll see the TV coming through. That's what the screenshots demonstrate quite clearly.

There are several solutions possible:

- use alpha "keying" instead. This will often lead to less smooth edges, but allows transparency of UI components on all hardware.
- don't let the picload code generate a transparent background, but render the icons into a format that precisely fits. Simplest way to do this is to assign just enough space (icons are 100x70 pixels, so 50x35 would work well for example).
- Use the background color of the list as the background color for the picon pixmap. This will probably not work, because that color isn't likely to be available in the picon's palette.

As a rule of thumb, you should always aim to avoid the word "transparent" in any skin, because it causes a lot more rendering, and the rendering itself gets more expensive. The attribute only applies to the UI part, and is not related in any way in being able to see the TV picture filtering through. I estimate that 80% of the "transparent" keywords in skins are "wrong" in this way.

[maigais]

have checked the black Picone on dreambox  

Attached Files

•  picon5.jpg   39.28KB   89 downloads

[littlesat]

Again... Do you have the same results in the graphical multi epg....
For the other vu boxes we did add somehing extra... A config that tells that the the drivers do not allow scaling and blending at once... Probably we have to do the same for the solo2.

[littlesat]

I suggest we should add the solo2 to what we did in the 650df patch in enigma2...

 

commit 650df541478a6f557dc4cec429f9174e835bafae
Author: pieterg <pieterg@users.sourceforge.net>
Date: Mon Feb 13 13:08:11 2012 +0100
configure.ac: vusolo, uno and ultimo don't support alpha blending acceleration
 
Enable the same hacks as for the duo
diff --git a/configure.ac b/configure.ac
index 54aaa5e..82984e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,7 +90,7 @@ if test x"$BOXTYPE" == "xdm8000" -o x"$BOXTYPE" == "xdm7020hd" ; then
AC_DEFINE(KEY_PLAY_ACTUALLY_IS_KEY_PLAYPAUSE, 1,[define when rc sends a KEY_PLAY event for its KEY_PLAYPAUSE key])
fi
 
-if test x"$BOXTYPE" == "xvuduo" ; then
+if test x"$BOXTYPE" == "xvuduo" -o x"$BOXTYPE" == "xvusolo" -o x"$BOXTYPE" == "xvuuno" -o x"$BOXTYPE" == "xvuultimo"; then
AC_DEFINE(FORCE_NO_BLENDING_ACCELERATION, 1,[define when the framebuffer acceleration does not have alphablending support, though the autodetection might indicate that it does])
AC_DEFINE(FORCE_NO_FILL_ACCELERATION, 1,[define when the framebuffer acceleration does not have fill support])
AC_DEFINE(FORCE_ADVANCED_REMOTE, 1,[define to fixup the input device identification when the remote control is actually an 'advanced' remote (with play/forward/rewind keys)])

So still another thing about VU we did "masked out" in the past....

Edited by littlesat, 1 August 2013 - 09:14.

[littlesat]

mmmm the duo2 should already be included there...

 

http://sourceforge.n...239194258bd758/

Edited by littlesat, 1 August 2013 - 09:48.

[Taapat]

After the last changes when loading picons in servicelist I have a lot of messages in enigma log:

[Picload] software decode picture ...
[Picload] setPara ...

I think that in log should be messages if there are errors, instead of loading each Picon.

I added a patch to reduce the messages in the log from picload.

Attached Files

•  0001-picload-stop-spam-in-log-if-no-errors.patch.zip   1.4KB   11 downloads

Edited by Taapat, 1 August 2013 - 18:16.

[Dimitrij]

Today's update.
Why is there a white background on some of the picons?

[littlesat]

Interesting that the white borders are picon related... And now also on the gme... So i suggest this is related to something in the picon it is not triggered at all due to the additions of the picons on the service list, but more on something triggered by new new accelerated blitting stuff... Can someone please attach such a picon here?

[Dimitrij]

Can someone please attach such a picon here?

Here

[littlesat]

I can at least confirm that the picon triggers the issue also here on my ET9K (GM-EPG and service list). So the issue is somehow triggered by the picon and not related to the picons in channel list feature.... I suggest we need help from Milo now.

Edited by littlesat, 2 August 2013 - 16:14.

[2boom]

Dima73

try

Attached Files

•  patched_problem_picons.zip   10.74KB   24 downloads

[littlesat]

How did you patch them and what is the difference?

[2boom]

I convert them with pngquant http://www.libpng.or...s/pngquant.html

[Dimitrij]

But why are these same picone no problem in the plugin HistoryZapSelector?

[littlesat]

Probably they are not scaled there.

[Dimitrij]

Today the updated image, probemy remained.