From: Petr Vandrovec <hidden> Date: 2003-03-17 10:40:31
On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
On 17 Mar 2003, Antonino Daplas wrote:
quoted
As Geert said, it's not just trivial, but logical to split fb_imageblit
into two.
So, are we gonna split it? This will also make hardware acceleration support
more clean. E.g. most sbus drivers do color expansion in hardware, and fall
back to cfb_imageblit() for the logo.
quoted
quoted
OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
while if depth != 0, then palette is in info->pseudo_palette ?
Yes. You can also say that if image->depth != var->bits_per_pixel, do
color expansion or reduction, whatever the case may be.
Hmmm... Note that image->depth can be larger than 8, while the image data is
still 8-bit. This is an inconsistency.
image->depth for logo must change to 8. Or remove depth completely after
splitting imageblit to paintchar & paintlogo, as currently depth is
useless anyway: target format is defined by framebuffer layout, not
by image->depth, and source format is hardwired to the code.
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote:
On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
quoted
On 17 Mar 2003, Antonino Daplas wrote:
quoted
As Geert said, it's not just trivial, but logical to split fb_imageblit
into two.
So, are we gonna split it? This will also make hardware acceleration support
more clean. E.g. most sbus drivers do color expansion in hardware, and fall
back to cfb_imageblit() for the logo.
It's up to James, though I vote for it. And I don't think any driver
has accelerated versions of fb_imageblit for the logo, since any
performance gained is probably minimal and it will involve too much work
for something that's going to be done only once.
quoted
quoted
quoted
OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
while if depth != 0, then palette is in info->pseudo_palette ?
Yes. You can also say that if image->depth != var->bits_per_pixel, do
color expansion or reduction, whatever the case may be.
Hmmm... Note that image->depth can be larger than 8, while the image data is
still 8-bit. This is an inconsistency.
I was thinking that if image->depth=8 and var->bits_per_pixel=4, then
the driver is in danger of going out of bounds when referring to the
pseudo_palette. But I forgot that the fb_show_logo() takes care of
avoiding that :-) And yes, current usage of image->depth is pretty
inconsistent and basically useless.
image->depth for logo must change to 8. Or remove depth completely after
splitting imageblit to paintchar & paintlogo, as currently depth is
useless anyway: target format is defined by framebuffer layout, not
by image->depth, and source format is hardwired to the code.
You're correct. If it's going to be split, image->depth becomes
redundant.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote:
quoted
On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
quoted
On 17 Mar 2003, Antonino Daplas wrote:
quoted
As Geert said, it's not just trivial, but logical to split fb_imageblit
into two.
So, are we gonna split it? This will also make hardware acceleration support
more clean. E.g. most sbus drivers do color expansion in hardware, and fall
back to cfb_imageblit() for the logo.
It's up to James, though I vote for it. And I don't think any driver
has accelerated versions of fb_imageblit for the logo, since any
performance gained is probably minimal and it will involve too much work
for something that's going to be done only once.
Wait until someone wants 256-color fonts ;-)
quoted
quoted
quoted
quoted
OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
while if depth != 0, then palette is in info->pseudo_palette ?
Yes. You can also say that if image->depth != var->bits_per_pixel, do
color expansion or reduction, whatever the case may be.
Hmmm... Note that image->depth can be larger than 8, while the image data is
still 8-bit. This is an inconsistency.
I was thinking that if image->depth=8 and var->bits_per_pixel=4, then
the driver is in danger of going out of bounds when referring to the
pseudo_palette. But I forgot that the fb_show_logo() takes care of
avoiding that :-) And yes, current usage of image->depth is pretty
inconsistent and basically useless.
quoted
image->depth for logo must change to 8. Or remove depth completely after
splitting imageblit to paintchar & paintlogo, as currently depth is
useless anyway: target format is defined by framebuffer layout, not
by image->depth, and source format is hardwired to the code.
You're correct. If it's going to be split, image->depth becomes
redundant.
That depends... How do we draw the monochrome penguin? Using image->depth is 1
or 8? The latter (current method) is slower, since we need to expand the
monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
driver afterwards.
And perhaps we may want to draw 32-bit ARGB images later?
So I see the following possible valid values for image->depth:
- 8 (logo with up to 256 colors and LUT)
- optional 1 (monochrome logo, if we don't want to expand?)
- optional 32 (ARGB image, dithering left to the driver?)
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:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
On Mon, 2003-03-17 at 20:18, Geert Uytterhoeven wrote:
On 17 Mar 2003, Antonino Daplas wrote:
quoted
On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote:
quoted
On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
quoted
On 17 Mar 2003, Antonino Daplas wrote:
quoted
As Geert said, it's not just trivial, but logical to split fb_imageblit
into two.
So, are we gonna split it? This will also make hardware acceleration support
more clean. E.g. most sbus drivers do color expansion in hardware, and fall
back to cfb_imageblit() for the logo.
It's up to James, though I vote for it. And I don't think any driver
has accelerated versions of fb_imageblit for the logo, since any
performance gained is probably minimal and it will involve too much work
for something that's going to be done only once.
Wait until someone wants 256-color fonts ;-)
When we do get that to that point, the entire interface will be
revamped. Imagine passing 128 bytes to draw a single character. This
is where Tile Blitting comes in.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en