From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>,
James Simmons <jsimmons@infradead.org>,
Linux Frame Buffer Device Development
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: fb_imageblit semantic
Date: 17 Mar 2003 22:24:31 +0800 [thread overview]
Message-ID: <1047911032.2684.79.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.21.0303171436170.17453-100000@vervain.sonytel.be>
On Mon, 2003-03-17 at 21:47, Geert Uytterhoeven wrote:
>
> IMHO always using an image depth of 8 is fine. That's a nice trade off between
> genericity and easy access of image data.
>
> Except for monochrome, there I prefer a depth of 1, since doing 1->8 and 8->1
> in a row is a bit too wasteful.
>
An exception to the rule :-) Well, I guess if it will significantly
benefit monochrome drivers...
> BTW, I just realized there's no need to distinguish between monochrome copy and
> monochrome-to-color expansion. The monochrome logo code just has to write the
> correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
> bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).
>
I remember mentioning this to you before, and you said that there might
be rare cases that fgcolor can be equal to bgcolor. However, using -1
instead for bg_color/fg_color may work, at least for the current setup
and only for monochrome, (except perhaps 32-bit monochrome, if there is
such a thing)
I still prefer splitting fb_imageblit() into two though, and still keep
image->depth for logo drawing only, to allow for future expansion.
.
> > Do we still use the LUT?
>
> Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there
Yes. Which also means logo drawing will also work for quirky drivers,
and the upper layer will be finally totally independent of the low level
drivers.
> are enough number of colors). But since imageblit is done for the logo only,
> doing the transform from LUT index to pixel value in imageblit is OK, I think.
>
Yes, I also prefer referring to the LUT whatever the format even for
character drawing. I don't expect any noticeable performance penalty
except for logo drawing. The way it's currently done is because,
looking at all drivers, not one fills up the pseudo_palette when bpp <=
8.
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
next prev parent reply other threads:[~2003-03-17 14:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-17 12:25 fb_imageblit semantic Petr Vandrovec
2003-03-17 12:40 ` Geert Uytterhoeven
2003-03-17 13:02 ` Antonino Daplas
2003-03-17 13:47 ` Geert Uytterhoeven
2003-03-17 14:24 ` Antonino Daplas [this message]
2003-03-17 14:46 ` Geert Uytterhoeven
2003-03-18 21:46 ` Detecting if the mode can be changed? Kendall Bennett
2003-03-18 23:50 ` Enumerating available display modes? Kendall Bennett
-- strict thread matches above, loose matches on Subject: below --
2003-03-17 10:40 fb_imageblit semantic Petr Vandrovec
2003-03-17 12:07 ` Antonino Daplas
2003-03-17 12:18 ` Geert Uytterhoeven
2003-03-17 13:01 ` Antonino Daplas
2003-03-14 10:52 Petr Vandrovec
2003-03-16 23:00 ` Antonino Daplas
2003-03-17 10:31 ` Geert Uytterhoeven
2003-03-14 10:18 Petr Vandrovec
2003-03-14 10:40 ` Geert Uytterhoeven
2003-02-20 1:09 FBdev updates James Simmons
2003-02-20 15:02 ` Dave Jones
2003-02-20 18:29 ` Petr Vandrovec
2003-02-21 0:24 ` Antonino Daplas
2003-03-03 20:35 ` [Linux-fbdev-devel] " Petr Vandrovec
2003-03-04 21:29 ` Jurriaan
2003-03-09 21:29 ` Petr Vandrovec
2003-03-09 22:27 ` Antonino Daplas
2003-03-09 22:54 ` Petr Vandrovec
2003-03-13 22:23 ` fb_imageblit semantic Petr Vandrovec
2003-03-14 9:22 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1047911032.2684.79.camel@localhost.localdomain \
--to=adaplas@pol.net \
--cc=geert@linux-m68k.org \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=vandrove@vc.cvut.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).