Micah Dowty wrote:
>
> Looks good. Just a couple of small questions:
>
> What about the video driver optimizations? I started a bit of work on the
> linear1 driver, but i didn't have much time. Hopefully I will have
> weekend time to get them working nicely. My weekends for the last couple
> weeks were occupied trying to get a working laptop...
We found your 4bpp driver pretty good for now in term of perfs, sow we will just
copy-paste the accelerator functions from that one into the 1 and 2 bpp. This will
probably yield the same perfs as for the 4bpp.
We'll write a n-bpp driver including the 1+2+4 bpp individual functions and acting as
a wrapper. We need a way for the client to swap.
We won't consider doing multiple-pixel-per-byte-at-a-time accesses for now (we seem to
have memset and memcpy do some good job for chunks of pixels that are aligned and
adjacent in the vid mem). I see this as a C prio task, which possible start has to be
after the next first release (but possibly before the next 2nd).
As suggested I want Philippe to do this for the next release. And I want to do this
release very soon so that you are free to start new things. One thing that I'd like to
see also in this release is a fix for the theme problem. I'll port PGUI on xcopilot,
so everybody will be able to test on a 68k architecture w/o a physical target.
> And about the native video format, what do you have in mind? I know
> PicoGUI is desperately in need of a palettized format, maybe with RLE
> compression. I don't know that a new format is completely necessary
> though.
> What about the bitmap/bitmask method of transparency PicoGUI currently
> uses? It does use more space than an chromakey type of transparency, but
> it allows the edges to blend without the expensive multiplication that a
> true alpha channel needs. Would a color-index-based transparency be
> helpful too?
To give you a precise answer, I should have a closer look in the code. My idea was to
have an intermediate format saving the overhead of reading+parsing the pnm format.
This would consist of something like a header giving the pix info, then a body in
binary format that could be fread() directly to the bitmap memory. I suppose that the
bitmap memory has an intrinsic format that is not dependent of the vid memory, right ?
So I don't care if this format is PGUI proprietary (it would become a PGUI standard),
since the images could be batch-generated during project build.
I intend to have such a format to have maximum perfs with images that are to be part
of a distribution (like themes, etc) and hence in rom. This is of course questionnable
for images that will be live-downloaded.
At the moment I care little about color and alpha channels. Little means a bit,
however (but in the future). I'd say the header tells how the body is to treat, and a
first version would handle for now monochrom bitmaps (1/2/4 bpp). Also compression
should be optional (remember I want this for frequently used images like icons, etc)
so it loads fastest w/o compression.
Maybe such a format exists already ? what about bmp ?
After the next 2nd release (but not before) I want to make an official announcement
from the PGUI community on the uClinux newgroup to tell PGUI is really available for
uC. Maybe also an announcement on Linuxdevices. What about doing a joint (Smartdata +
M.Dowty) article ?
By the way, why not give these next releases a cool name:
'first next' -> <CoolName>_pre
'second next' -> <CoolName>
Cheers,
Pascal.
--
Pascal Bauermeister
Head of Software Development
SMARTDATA
PSE-A / EPFL
CH-1015 Lausanne
http://www.smartdata.ch
mailto:[EMAIL PROTECTED]
Phone: +41 (21) 693 84 98
fax: +41 (21) 693 84 91
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
