On Thu, 15 Mar 2001 11:02:02 Pascal Bauermeister wrote:
> 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.
This just means moving the code to actually set the mode (vs the init
itself) into the driver's mode set function, then make a client-callable
request that will set the mode and resize the root divnode.
>
> 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).
This definitely seems less than optimal, but better than the current driver
certainly.
I've started the optimization for linear1, need to fix a few bugs before I
commit.
>
> 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.
Neat
>
>
> > 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 ?
Actually, the image loader converts it to a format specific to the current
video mode, that is simply copied to video memory when needed. But, it
would be nice to have a format that is slightly compressed (something the
m68k can handle) and supports palettes to reduce file size.
>
> 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.
ok
>
> 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 ?
I thought about it. It supports RLE, right? I'll look in my copy of
"Encyclopedia of graphics file formats"
>
>
> 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>
Nifty! I'll think about that
>
>
>
> 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
