Rockbox

Can you please resubmit this patch in unified diff format?
Also, it looks like we are doing an awful lot of processing
each time through the WPS display, is there a way we can
move all of the color calculations and text parsing into the
wps load, and then only have to apply the LCD color changes
at display time?

Latest version of the patch supports foreground and background and is simpler
than the first patch. There are unresolved issues with sublines (not easily fixed
either, due to the way gui_wps_refresh separates the lines/sublines processing
and images display into two loops). For now, limit color changes to lines, scroll
lines and bitmaps.

Here’s an updated version of the iAmp theme that exploits the new features, as
well as corrects several layout problems with the current CVS version.

Also, it looks like we are doing an awful lot of processing
> each time through the WPS display, is there a way we can
> move all of the color calculations and text parsing into the
> wps load, and then only have to apply the LCD color changes
> at display time?

Not easily. There are several display elements that aren’t displayed
“in order” and that makes it very difficult to parse colors once.

scroll lines - these are actually displayed in a separate thread and
the current fgcolor/bgcolor might be wrong. I’ve fixed this by having
the scrollinfo structure store the fgcolor/bgcolor at the time when
the scroll line was created, and temporarily restoring those colors as
needed.

sub lines - these can “pop into existence” at unexpected times, and
this can cause the fgcolor/bgcolor for the subline to “bleed” into
graphical elements such as images, the statusbar, the progress bar,
and so on.

images - these are displayed in a separate loop (inside the function
wps_display_images) which is outside the normal processing of lines.
This means images take on whatever was the last fgcolor/bgcolor,
typically the color of a subline.

One fix I attempted was to add fgcolor/bgcolor attributes to every
line, subline and image. This was damn ugly and still didn’t work very
well (still has exceptions where the color bleeds between lines). That
technique is also limited; effectively colors are limited to bands across
the screen. It won’t be possible to make complex interfaces like that.

What are your thoughts on completely rethinking the WPS
process so that at WPS load, everything is processed into a
list of lists (linked list? array?) of structures, or
possibly a hierarchy of structures to indicate lines,
conditionals, etc. which would allow colors to be applied
and removed at any level.

Basically it seems like the system of storing all attributes
of the WPS as the text of the WPS is no longer effective as
we add something like color which requires more than
switching 2 levels of characters in order to determine behavior.

“What are your thoughts on completely rethinking the WPS
process so that at WPS load, everything is processed into a
list of lists (linked list? array?) of structures, or
possibly a hierarchy of structures to indicate lines,
conditionals, etc. which would allow colors to be applied
and removed at any level. "

Funny that you should mention that. I’m currently in the
process of rewriting gwps-common to use a display list.
I can summarise the idea as follows:

1) the display list is an array of display items, each
    item has x, y, w, h, fgcolor, bgcolor

2) items are text, images, or specials (eg, the peak
    meter is a special)

3) the wps is parsed once per frame and a display
    list is contructed; this is a necessary evil because
    of conditionals

4) the display list is rendered in-order, with items
    further down the list having a closer z-order, so
    they're drawn over items with a further z-order

As the display list is being constructed in wps_refresh
any dynamic tags (eg, %pv) are converted into static
texts. They are then dumped into the display list with
an appropriate x,y as text items.

The big benefit of this technique is that charcell LCDs
can still use display lists. Every display item is roughly
the same as an existing line or subline.

The reason to do display lists is it is now possible for
every item to have attributes (eg, color) and any order
(text behind images, images behind text). It’s also a
necessary step towards compositing; the idea of using
alpha channels to blend display items together.

I already have some code partially working. I have the
display lists working for conditional images, static
images, a background image (yay), peak meters, the
progress bar, and text strings. It’s rough - doesn’t
support sublines or scrolling lines - so I’m not ready
to start throwing patches around.

The X,Y and FG,BG of a display item can be preprocessed, and
I think that is probably something worth doing. I could of
course be talking out of my ass, but my concern is that with
the additional complexity supported by this, and the types
of UIs that people will hopefully start to design using
absolute text coordinates and other neat stuff, we will end
up spending too much time processing the WPS and the display
will take up too much CPU and lag.

So, how about, in the WPS load we build a list (fixed size
like the images list?) of absolutely positioned text
elements. The user can either specify absolute text
coordinates as the first thing on a line, taking it out of
the normal line processing, or they can leave it in the
normal processing order and it will get assigned a
0,fontheight*linenum coordinate. This precalculates the Z
ordering which is important later in processing, saves work
later, and adds support for absolute text positioning at the
same time.

I would also prefer to save 30ish instructions per-color by
repacking them as 3 bytes in the wps during load so that the
color can be constructed as fmt[2],fmt[3],fmt[4] when the
final display list is generated for each display. This adds
little complexity the load, and changes nothing except for
only using 3 of the 6 elements in the buffer at display time.

Great work, btw, this is something that will really improve
rockbox for everyone, sorry if I’m being overly picky (as I
haven’t a leg to stand on or any kind of authority or anything).

(I’d be happy to write the method for repacking all of the
colors on a line if you like the idea but don’t want to
write it)

how to use colorised-iAmp.zip ?
it contains one binary file “colorised-iAmp” which isn’t a
wps file…

I can’t even unpack colorised-iAmp.zip:
“it does not appear to be a valid archive”.