Yoshinori K. Okuji wrote:
> On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote:
>>> Compression might make the performance horrible, because PPF is very
>>> optimized.
>> When there is a caching implemented in a one day, it's only initial
>> cost. So far I haven't seen performance probl
Vincent Pelletier wrote:
> By the way, there is already a font format handled by IEEE1275
> frame buffercards.
> - From the standard :
>
> set-font ( addr width height advance min-char #glyphs -- )
> Set the current font as specified.
>
> So I think they can handle arbitrary-sized glyphs.
> I ca
Vincent Pelletier wrote:
> By the way, I think we should start a discussion on the API common to
> all architectures for framebuffer handling.
Currently there is a terminal implementation that uses video subsystem
to render screen. So basicly in every arch there must be a video driver
if you want
Hello,
I've been trying to get some C++ running (now that I can print "Hello
World" from OF, I'd like to move my "Hello World" C++ kernel to
PowerPC), but it has been without much success.
I've finally figured out that there are these small data sections
which I was not taking care of in my
On Saturday 26 November 2005 03:36 pm, Vincent Pelletier wrote:
> By the way, there is already a font format handled by IEEE1275
> frame buffercards.
> From the standard :
>
> set-font ( addr width height advance min-char #glyphs -- )
> Set the current font as specified.
If my understanding is cor
On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote:
> > Compression might make the performance horrible, because PPF is very
> > optimized.
>
> When there is a caching implemented in a one day, it's only initial
> cost. So far I haven't seen performance problems with this. But then
> ag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 26 Nov 2005 02:28:53 +0200
Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote:
> Yoshinori K. Okuji wrote:
> > If you want to improve it, feel free to do it. It is our own
> > format. But I think the byte order was set conveniently.
>
> Byte order is