From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 20 Feb 2013 23:33:38 +1100

On 20 February 2013 22:34, Thomas Martitz <kugel_at_rockbox.org> wrote:


> I start with list.c because that's the most extensive user, but other
> screens can follow easily, e.g. various plugins. The API that I suggest can
> print the whole line (indent, spacing, icon and text) in a single call so
> it's generally attractive.
>
> Ignoring plugins, 99% of the UI is drawn by list.c, so yes adding API's
for its use would seem attractive, but that will almost certainly end up
being wasted effort. I'm really aiming to have the lists entirely drawn by
the skin engine by the next release which would make any effort here
redundant.

So, in that spirit I'd advocate you just doing the semi-nasty hack and
adding a bit to the style flags so the scroller can redraw the seperater
line (or just piggy-back off the gradient num_lines bits). Once the skin
engine is doing the list drawing the scroller can be returned to a dumb
text drawer (all line decorations would be drawn onto the backdrop buffer
so the scroller clearing the line would leave them intact.)


>
>
>> If all you want is a line separator then why is it not a simple 1 line
>> lcd_hline() call in the draw_list() loop?
>>
>
> This is what the current version on gerrit does. The problem is that
> scrolling breaks it (the scroll engine redraws the line selector which
> clears the separator). And it sucks from a software-architecture POV: The
> line selector is currently drawn in firmware, the separator would be drawn
> in apps (in this scenario). So two completely different places although
> they are essentially very similar (style attached to each line). I really
> want to clean up this mess for good before moving forward with the
> separator.
>
> As above, in the interest of not wasting developer time I'd recommend
doing the sucky way knowing it is temporary.



>
>> Thinking about it now, it would be pretty cool to register a callback
>> (per viewport) for the scroll engine to call which would do the line
>> drawing instead of the current code. (It would have to be per viewport
>> because it is very likley to have a skin scrolling line and the list
>> scrolling line both scrolling at the same time, though a generic one would
>> be needed for default which should "just work").
>>
>
> I have the beginnings of a scroll engine rework which does a callback (per
> line, and each line has a viewport associated). But even the current scroll
> engine already stores a viewport pointer for each line, that is set when
> the line is redrawn.
>
> This I'm interested in seeing. I'm starting to wonder if the scroller
really needs the viewport pointer per line? If this was changed to store
just the pixel rectangle to draw in (so the line number is also removed,
and relative to the screen, not viewport) then it wouldn't necessarily
overdraw the decorations. The callbacks becomes an issue, but I agree that
using a callback is the way to go to remove this decoration drawing from
firmware.

Jonathan
Received on 2013-02-20