Unexpected viewport behavior

[HornetMaX]

Let's imagine the .sbs defines the UI viewport as follows:

Code: [Select]

%Vi(t,0,8,-,-,1)	

With an 8pt font, the Sansa Clip+ display is 8 lines tall.
The above means hence that the custom UI viewport spans lines 2 to 8.
This is confirmed creating a .wps as follows:

Code: [Select]

1 WPS
2 WPS
3 WPS %St(statusbar)
4 WPS
5 WPS
6 WPS
7 WPS
8 WPS
9 WPS
0 WPS

With the above .sbs ans wps, the display will show an empty first line and lines "1 WPS" ..."7 WPS" will be displayed on lines 2 to 8.

However, modifying the .wps as follows:

Code: [Select]

%V(0,0,-,-,0)
1 WPS
2 WPS
3 WPS %St(statusbar)
4 WPS
5 WPS
6 WPS
7 WPS
8 WPS
9 WPS
0 WPS

Lines "1 WPS" ... "8 WPS" are displayed on lines 1 to 8.

Said otherwise, it seems to me that the X and Y coords in the %V and %Vd commands are absolute to the screen and not relative to the UI viewport.

If that's the case, then I don't get the interest of defining a UI viewport in the .sbs if, anyway, it can be overridden by any %Vd in the .wps and as the .wps have no way to know the size/position of the UI viewport.

In the .wps you are sure to honour the UI viewport if and only if you always draw in the default viewport (i.e. if you don't use any %V / %Vd), which is a hell of a constraint.

Am I missing something ?

MaX.

EDIT: typo fixed.

[[Saint]]

In the .wbs you are sure to honour the UI viewport if and only if you always draw in the default viewport (i.e. if you don't use any %V / %Vd), which is a hell of a constraint.

Paste your entire theme, or link to it, instead of some fantasy code, so we can have a look at what you're actually doing instead of speculating on what might be wrong with code that other people manage to manipulate.

btw: So in future searches can point to this correctly, it's ".wps" ("while playing screen")


[St.]

[HornetMaX]

I'll paste the entire theme here, as the forum does not allow to attach .zip, .fms, .sbs (I can understand for the .zip, but why not .sbs nor .fms ?).
Sorry for the wps typos, I'll edit the original message.

MaX.

vp2.cfg:

Code: [Select]

wps: /.rockbox/wps/vp2.wps
sbs: /.rockbox/wps/vp2.sbs
fms: /.rockbox/wps/vp2.fms

font: /.rockbox/fonts/08-Schumacher-Clean.fnt

vp2.sbs:

Code: [Select]

# UI viewport.
%Vi(-,0,8,-,-,1)

%V(0,0,-,8,0)
STATUS BAR

vp2.wps:

Code: [Select]

# Enable status bar.
%we
%V(0,0,-,-,0)
1 WPS
2 WPS
3 WPS %St(statusbar)
4 WPS
5 WPS
6 WPS
7 WPS
8 WPS
9 WPS
0 WPS

vp2.fms:

Code: [Select]

# Enable status bar.
%we
1 FMS
2 FMS
3 FMS %St(statusbar)
4 FMS
5 FMS
6 FMS
7 FMS
8 FMS
9 FMS
0 FMS

Here's the display output for WPS and FMS:

WPS:

Code: [Select]

STATUS BAR
2 WPS
3 WPS top
4 WPS
5 WPS
6 WPS
7 WPS
8 WPS

FMS:

Code: [Select]

STATUS BAR
1 WPS
2 WPS
3 WPS top
4 WPS
5 WPS
6 WPS
7 WPS

See the issue ?

[JdGordon]

Point out where it says viewports *aren't* screen relative and that will be fixed... Viewport coordinates have always been relative to 0,0 of the LCD (i.e top left). and of course nothing requires you to stay in the default viewport in the wps (just expect wierdness if you dont)

[HornetMaX]

Point out where it says viewports *aren't* screen relative and that will be fixed... Viewport coordinates have always been relative to 0,0 of the LCD (i.e top left). and of course nothing requires you to stay in the default viewport in the wps (just expect wierdness if you dont)

Hi,
nowhere it is said viewports *aren't* screen relative.
But I'd think that it would be nice to be able to define viewports that are relative to the default viewport.

%Vd(0,0,...)  --> viewport relative to screen
%VD(0,0,...)  --> viewport relative to default viewport (if defined, else assume full screen).

It would semplify a lot the code of .fms/.wps in some occasions.

MaX.

[[Saint]]

Just a quick note for others that happen across this...

...And of course nothing requires you to stay in the default viewport in the wps (just expect wierdness if you dont)

This isn't entirely true.

You can draw in/out of the default viewport in many situations. An example would be an image that's always displayed, if there's no viewport that overlaps it there's no need to draw this in it's own viewport.

Of course it's a lot "cleaner" to, but, not necessary.

Additionally, if no viewports are used at all, then it doesn't matter what you draw in the default viewport.

The usual way of doing things (if you want to save yourself hassle) is not to mix the two, this is where "weirdness" comes into play.

The "weirdness" in question is usually the area in the default viewport failing to clear when a conditional element is no longer true. However, depending on what's going on in the theme, this may not be an issue as it may be immediately overdrawn by a viewport/image when the condition goes "false".

I'll add that I don't really like the practice of mixing default/user-defined viewports...it actually really annoys me as a themer, but there are some cases where it's a: quite acceptable, or b: just plain easier to do so where it might not necessarily provide any ill effect at all.

Just don't expect that it *definitely* won't cause any drawing issues.


[St.]