: Also why is there a a - and a + sign used before the numbers.
The - and + reference the two files being diffed, and match
the upcoming patch lines which are preceded by - and +.
In your case, the - file references the first file and the +
references the second file in the diff.
: @@ -41,6 +41,
> WPSes included with Rockbox could be provided pre-parsed, with the
> core having the ability to load parsed WPSes, while unparsed WPSes go
> throug the parser plugin first (which could I suppose store the
> current WPS as a temporary file, to be used upon reboots)?
> Offloading the parsing to a
: With regards to creating a thread on the second core, there is no
: guarantee that this will be available even on PortalPlayer machines, so
: the code to create a thread on the second core would be something like:
:
: my_thread = create_thread_on_core(COPROCESSOR, my_function, my_stack,
: sizeof
> Imagine Rockbox was open for anonymous
contributions and some lawyer finds a piece of code which infringes the
copyright of some company. Who would have the problem then? Björn, Daniel
and
Linus, because they are responsible for the project and they host the
project on
their server. So you say th
: OK, now I think I understand what you're saying. The unified cache would
: still be static though, right? Instead of five 10kb (or 45kb or
: whatever) buffers we'd have a single (probably larger, somewhere around
: 50kb?) buffer used for all fonts, with everything going through the font
: cache &
: Wouldn't this mean that the font would have to be reloaded from disk
: every time the user switched from one screen to another? That means at
: least a 1-2 second delay (much more if the disk is spun down) every time
: the displayed font changes.
What I'm saying is that the font buffers could be
: concerned about // style comments? They're much
: quicker to type, and also allow the use of /* */ to quickly disable blocks
: of code.
Quicker to type should never be a programmer's priority, IMO.
Far more important is maintaining a consistent style.
Regards,
Greg
: If we increase each font buffer to 45kb we can ensure that only the
: biggest fonts go through the cache (about 74% of fonts then are small
: enough to be loaded entirely). Obviously that increases overhead quite a
: bit (from ~50kb to ~225kb).
It sounds like the font buffer should be shared bet
: My prev post was more of an oblique plea to someone who knows the font
: code to please give me some pointers. Worst case scenario that the font
: code does need a major overhaul (which may or may not happen), all I
: would plan on doing would be leaving a few font slots free for whoever
: wants
: iPod Video
:
: Rockbox works on it, but there's no audio. No one seems to have worked
very
: hard yet at figuring it out. This probably takes some dissassembly.
Otherwise
: this of course resembles the Color and Nano models.
Why can't we use the code that the iPod Linux folks have for
gett
: 2) Moving the #ifs into the bitmap SOURCES file simplifies the code a
: lot, but currently the sizes of the bitmaps still need to be defined in
: the C file itself - the size isn't taken from the output from bmp2rb.
: I've ignored this for now.
Its been awhile since I've reviewed much Rockbox
: I could really use some assistance to make the X11 sim to support colors.
We
: have several targets with color LCDs now, and I hope we'll see even more
of
: them appearing in the future. Having the x11 sim non-functional for these
: targets will hamper development.
I barely have any time either,
12 matches
Mail list logo
