Rockbox

Tasklist

FS#11550 - %x() image "drawn below" %pb() in the same viewport doesn't show up

Attached to Project: Rockbox
Opened by Andrew Freedgood (kaiscene) - Wednesday, 18 August 2010, 05:54 GMT
Last edited by Jonathan Gordon (jdgordon) - Saturday, 09 October 2010, 10:02 GMT
Task Type Bugs
Category Themes
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Build: r27821
Player Type: Sansa Clip+

Description:
Prior to r27821 (changes to the %pb() tag), the following WPS code would display both "pbbackground.bmp" and the progress bar in the same location on the screen. The progressbar would appear "on top" of the background image.

[....]
%V(0,0,-,8,2)
%x(a,pbbackground.bmp,32,0)
%pb(32,0,66,6,pb.bmp)

r27821 causes the %x() image to not display at all. Maybe the progressbar is completely covering it?


Workarounds:
*(1) when rockbox starts up it, it automatically loads the theme and the %x() is not displayed. (2) load any other wps. (3) load the original wps from (1), and the %x() image shows up.

*Adding a syntactically-unnecessary %xd() does fix the problem without resorting to reloading the theme.
[....]
%V(0,0,-,8,2)
%x(a,pbbackground.bmp,32,0)
%xd(a)
%pb(32,0,66,6,pb.bmp)


The full theme is attached, which includes the images pbbackground.bmp and pb.bmp.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Saturday, 09 October 2010, 10:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  r28184
Comment by Andrew Freedgood (kaiscene) - Wednesday, 18 August 2010, 06:33 GMT
Further testing shows that the %pb() tag doesn't affect how the %x() is displayed.
A viewport consisting of only the %x() tag fails to display the %x() image.

Example:

%V(0,0,-,8,2)
%x(a,pbbackground.bmp,32,0)
# will show nothing

%V(0,0,-,8,2)
%x(a,pbbackground.bmp,32,0)
%xd(a)
# shows the image.
Comment by Thomas Winkler (Tolao) - Sunday, 22 August 2010, 17:04 GMT
Having tested various revisions, I found out that %x is no longer working exactly since r27787.

r27771, r27780, r27785 and r27786 all showed the picture with %x(a,a.bmp,0,0) just fine.

Workaround for now is to use %xl(a,a.bmp,0,0)%xd(a) instead.

As Andrew already commented, this has nothing to do with %pb. Just %x is broken. Sometimes the picture is drawn completely, sometimes incompletely (looks like noise in my case) and sometimes not at all.
Comment by Jonathan Gordon (jdgordon) - Monday, 23 August 2010, 01:30 GMT
are you absolutely sure it is 27787? I dont see anything in the diff which obviously breaks it :/
Comment by Thomas Winkler (Tolao) - Monday, 23 August 2010, 09:35 GMT
I tried on fuzev2 normal build.

Just checked again. Put r27786 on the player, selected the wps file with only
%V(0,95,-,16,1)
%x(a,a.bmp,0,0)
went to wps, image was shown. rebooted, continued playback, image was shown. rebooted again, continued playback, image was shown.

Now put r27787 with that same wps file on the player. Selected the wps file, went to wps, image was shown. rebooted, continued playback, no image.

I'll have a look at the changes made in r27787 now. Maybe I can help you to narrow down where the problem comes from.
Comment by Thomas Winkler (Tolao) - Monday, 23 August 2010, 10:37 GMT
okay.. commenting out

1004 if (img->using_preloaded_icons)
1005 {
1006 img->loaded = true;
1007 list->token->type = SKIN_TOKEN_IMAGE_DISPLAY_LISTICON;
1008 }
1009 else
1010 {

and

1017 }

in r27787 makes %x working.
Comment by Thomas Winkler (Tolao) - Monday, 23 August 2010, 10:44 GMT
The problem is that the path "if (img->using_preloaded_icons)" is entered when it shouldn't be... changing only line 1004 to if(0) is enough to prevent the problem from occuring.
Comment by Jonathan Gordon (jdgordon) - Monday, 23 August 2010, 10:57 GMT
very very wierd :/

umm... have you got it going in gdb there? is img->using_preloaded_icons true there? it shouldnt be
Comment by Thomas Winkler (Tolao) - Monday, 23 August 2010, 11:13 GMT
I added DEBUGF()s in the two paths there in skin_parser.c. But in the uisimulator the else path was chosen.

No I didn't use any debugger. Can I even do it in the player without special equipment?
Comment by Jonathan Gordon (jdgordon) - Monday, 23 August 2010, 11:16 GMT
the sim runs fine in gdb, you cant use gdb on the actual target though
Comment by Thomas Winkler (Tolao) - Monday, 23 August 2010, 11:17 GMT
Too bad because the problem seems to happen only on the target after reboot :)
Comment by Thomas Winkler (Tolao) - Tuesday, 24 August 2010, 12:55 GMT
What could it be then? When I add
img->using_preloaded_icons = false;
before the line
if(img->using_preloaded_icons)
it works as well.

So yes, using_preloaded_icons is indeed true there!! And this only happens on boot, so maybe the simulator 'boots' differently?
But it does happen on multiple targets (see that the original poster used a clipplus).
Comment by Teruaki Kawashima (teru) - Saturday, 09 October 2010, 08:38 GMT
AFAIK, the skin beffur isn't cleared by zero, so i think there could be chance that the img->using_preloaded_icons is ture.
i think the bug is fixed by r28184.
Comment by Thomas Winkler (Tolao) - Saturday, 09 October 2010, 10:00 GMT
Teruaki, seems you're right, I've booted up r28220 many times now and the images with %x were indeed always drawn correctly.

Loading...