Rockbox

Tasklist

FS#2838 - adds color to wps themes

Attached to Project: Rockbox
Opened by Nathan Hand (nathanh) - Wednesday, 14 December 2005, 12:38 GMT
Last edited by Peter D'Hoye (petur) - Monday, 30 July 2007, 20:48 GMT
Task Type Patches
Category Themes
Status Closed
Assigned To No-one
Operating System
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Simple little patch to change colors within the WPS. Works for bitmaps,
lines, sublines and scrolling lines. It won't look as fancy as the iRiver
H300 interface (bitmaps are still all in one color) but it is a damn sight
better than black and white.

Currently only supports changing the foreground color. I've included a
version of iAmp WPS to demonstrate what can be done.
This task depends upon

Closed by  Peter D'Hoye (petur)
Monday, 30 July 2007, 20:48 GMT
Reason for closing:  Out of Date
Additional comments about closing:  the idea isn't bad though...
Comment by Brandon Low (lostlogic) - Thursday, 15 December 2005, 16:55 GMT

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?
Comment by Nathan Hand (nathanh) - Saturday, 17 December 2005, 00:29 GMT

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.
Comment by Nathan Hand (nathanh) - Saturday, 17 December 2005, 00:30 GMT

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.
Comment by Nathan Hand (nathanh) - Saturday, 17 December 2005, 01:03 GMT

> 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.
Comment by Brandon Low (lostlogic) - Saturday, 17 December 2005, 06:07 GMT

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.
Comment by Nathan Hand (nathanh) - Saturday, 17 December 2005, 07:53 GMT

"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.
Comment by Brandon Low (lostlogic) - Saturday, 17 December 2005, 13:33 GMT


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).
Comment by Brandon Low (lostlogic) - Saturday, 17 December 2005, 13:35 GMT

(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)
Comment by Anonymous Submitter - Sunday, 18 December 2005, 17:29 GMT

how to use colorised-iAmp.zip ?
it contains one binary file "colorised-iAmp" which isn't a
wps file...
Comment by Matthias Mohr (aka Massa) (mmohr) - Sunday, 18 December 2005, 21:47 GMT

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

Loading...