: 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 &
On Mon, 2006-02-27 at 14:13 -0700, Greg Haerr wrote:
> What I'm saying is that the font buffers could be shared
> between all characters of all fonts. By keeping track of the
> font number as well as the character, all displayed characters
> would be cached from the same area, subject to LRU load
: 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
On 2/27/06, Bluechip <[EMAIL PROTECTED]> wrote:
> There is currently a discussion on the
> possibility of using the ID3v2 Tag Sort Order to
> define the order tracks are sorted - if it is
> approved I think it would serve as a _simpler_
> solution to the same end.
What with sorting directories tha
On Mon, 2006-02-27 at 11:33 -0700, Greg Haerr wrote:
> It sounds like the font buffer should be shared between
> fonts, so that each "loaded" font doesn't use an entirely
> new buffer.
Wouldn't this mean that the font would have to be reloaded from disk
every time the user switched from one screen
: 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.
I personally see no impact of mixing /
: 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
You'll also need xorg-x11-devel packages (assuming you're using
Fedora/RH/SuSE or derivatives thereof). That's why your SDL didn't
include X11 support, you didn't need to download the entire XOrg source
and compile yourself, all you need is the *-devel package.
Also keep in mind that the sim doesn
: 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
For Fedora core 3, that would be
yum install SDL-devel
-Tristan
On 2/27/06, Dan Everton <[EMAIL PROTECTED]> wrote:
> How you install the packages that the SDL simulator requires to run will
> vary between different Linux distributions. For Debian and Ubuntu for
> example, you would type something
How you install the packages that the SDL simulator requires to run will
vary between different Linux distributions. For Debian and Ubuntu for
example, you would type something like
sudo apt-get install libsdl1.2-dev
and for Fedora it might be (untested)
yum install libsdl1.2-dev
Hav
How to? Is SDL some package that is installed by
default on most Linux distributions or something?
Cause nowhere in the twiki is it mentioned where to
get it & how to install it (if you must do more than a
configure/make/make install) on the source.
I download sdl-1.2.9 from libsdl.org, configure,
There is currently a discussion on the
possibility of using the ID3v2 Tag Sort Order to
define the order tracks are sorted - if it is
approved I think it would serve as a _simpler_
solution to the same end. Of course the
down-side is that it becomes the users'
responsibility to go back and r
Hi,
Are there any plans to implement proper directory sorting in rockbox?
for some reason, I expect "Sébastien Schuller" to be placed before "Syd
Barrett", not after as it is now.
Of course, full unicode sorting (i.e. implementing full strcoll()) is
almost impossible, but in the -00FF ran
Hi friends
Thanks to excellent scriptting work done by Tomas Salfischberger and
additional server powers kindly donated by jaebird, lostlogic and linuxstb,
we're now finally introducing the
Rockbox Distributed CVS Builds
Our main build server has struggled harder and harder to keep up with
I believe you will find that ID3-TagIt (.de) supports these fields.
I am aware I pressed reply, against the
instructions in block caps, it was the easiest
way to quote the original note. If this causes
some weird threading issue that upsets the
purists, please say something that it may not h
I followed your advice (and I already had: I'd done a make clean,
followed by make and make zip, and had copied that over to the ipod
before I made my initial email, but just to be sure, I created a new
build directory and compiled anew.)
The codecs on the iPod are the same as the codecs from
[EMAIL PROTECTED] wrote:
> when I compile the iPod video target with64MB memory, I get a usable
> firmware that uses all 64MB of memory, but none of the codecs or plugins
> work.
Are you definitely using codecs and plugins compiled for your new 64MB
Rockbox? Codecs and plugins are compiled and li
when I compile the iPod video target with64MB memory, I get a usable
firmware that uses all 64MB of memory, but none of the codecs or
plugins work.
To compile to 64MB, I changed line 757 of tools/configure from
memory=32 # 30GB models have 32MB, 60GB have 64MB
to
memory=64 # 30GB models have 32
19 matches
Mail list logo
