Thread (8 messages) 8 messages, 3 authors, 2003-01-22
  • fonts · Geert Uytterhoeven <geert@linux-m68k.org> · 2003-01-11
  • Re: fonts · Geert Uytterhoeven <geert@linux-m68k.org> · 2003-01-11
  • Re: fonts · Antonino Daplas <hidden> · 2003-01-12
  • Re: fonts · Geert Uytterhoeven <geert@linux-m68k.org> · 2003-01-12
  • Re: fonts · James Simmons <hidden> · 2003-01-15
  • Re: fonts · Geert Uytterhoeven <geert@linux-m68k.org> · 2003-01-21
  • Re: fonts · Antonino Daplas <hidden> · 2003-01-21
  • Re: fonts · Geert Uytterhoeven <geert@linux-m68k.org> · 2003-01-22

Re: fonts

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2003-01-22 09:25:08

On 22 Jan 2003, Antonino Daplas wrote:
On Wed, 2003-01-22 at 00:14, Geert Uytterhoeven wrote:
quoted
On Wed, 15 Jan 2003, James Simmons wrote:
quoted
quoted
quoted
The cfb_imageblit() function exhibited the same behavior.  I think we
both made the wrong assumption that all monochrome bitmaps are packed. I
think the rule is:

    The first pixel on the next scanline is always at the next byte from
    the last pixel of the current scanline.  

So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
last 4 are used as padding.  It's worse with a 4x6 fonts where the
4-bits are just duplicated in the other nibble.
Yes.
All the font data should be packed and byte padded at the end of each 
scanline worth of data. Also most accel engines expect the data to byte 
packed.
What do you mean with `each scanline worth of data'? Data for one character, or
data for the whole font (i.e. all characters)?
I meant for each row of bits representing a pixel in a bitmap, the start
index and the size of each row will be byte-aligned.  So, the padded
version.
  [...]
The latter is very difficult to support by most common hardware as they
require the padding.  Actually, some, maybe most, cards require more
than a byte padding. 
  [...]
If we do need to support both versions, then we need extra fields to
fb_image, such as clipx1 and clipx2, where: 

	image.clipx1 = starting index;
	image.clipx2 = clipx1 + width;

(Do we also need something similar for the y coordinate?)
Or add sx and sy, cfr fb_copyarea. Makes clipping behave the same for both.
I think I'll let you and James decide on this :-) 
I'm happy with the current scheme. I just wanted to be 100% what James meant
with `All the font data should be packed and byte padded at the end of each 
scanline worth of data.'.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help