Subject:
Re: Conversion of PIXELVALs <-> COLORVALs
From:
Morten Rolland ####@####.####
Date:
20 Dec 1999 08:23:33 -0000
Message-Id: <385DF3DB.B923ACAD@screenmedia.no>
Hello Greg,
Your latest changes seems very nice! I/we have not been able to test it
yet, but will do.
> First, we stay with a single, modified GrArea() call. The modification
> is to pass a single PF_xxx type with GrArea that tells the server
> what type of data is being passed. This keeps alot of duplicate
> code out of the server, and keeps the opcodes down, which
> aren't really needed.
Yes. The GrArea will not spend most of its time in the switch
logic anyway I guess...
> Second, we use your good idea of stating that the server will
> always translate certain pixel formats. Now, here's the tricky part.
> I suggested that RGB COLORVALs be always translatable. You
> want TRUECOLOR888.
Oh, well. I'm not sure if I really wanted 3-byte packing of the
24-bit case.... I must have called it by the wrong name by accident.
It will reduce the size of the request, at the expense of
simplicity when building the image at the client. Don't settle
for 3-byte packing if you think 4-byte alignment is better;
I will probably not use the portable case at all anyway.
> Well, the only difference between these
> two is actually a 24bpp vs 32bpp packing. So it's not a big deal,
> and the server will always call GdFindColor on the data (which
> isn't fast, BTW).
If we choose wrong, we may not be able to utilize accels at a
later stage when optimizing. I can ask at the GGI mailing list
what direction hardware is heading WRT 3-byte/4-byte 24bpp layouts,
I'm fairly sure they can tell me more than I want to know
about this issue:-)
> We add a PF_COLORVAL and rename
> PF_TRUECOLOR24 to PF_TRUECOLOR888 to make this work.
As said, don't change anything in this respect fro my sake only;
I would hate to realize I have prevented "the right thing" from
happening!
> Now, here's the other part. The PF_xxx values can be rewritten
> as mask values, and the server can return via SCREENINFO
> the entire set of masks that it will allow, or translate. This
> allows a client application to specify a hardware PIXELVAL
> value directly in a GrArea() call. Here's the important part:
> if you want speed, there's only *one* way we're going to get it.
> That is, the client builds an image packet, it gets queued,
> finally sent over, and then the server *must* call the screen
> driver bitblit routine, it CANNOT muck with the data. Note,
> currently, that's NOT the way GrArea works. GrArea unpacks
> the data and calls DrawPixel. In my earlier work with
> bitblit, added recently, I found an order of magnitude
> difference between, believe it or not, a hand-coded
> for() loop and an inline memset() libc call.
I hope the memset was the faster one, no? :-)
> So, for
> speed, the client's got to build the hardware pixel
> values, period. Of course we don't demand this,
> since PF_COLORVAL and PF_TRUECOLOR888 will
> always be translated.
Yes!
> Anybody can add PF_xxx translations to the GrArea server
> entry point, and convert data, although this
> will never provide speed. This allows say, 16bpp
> clients to talk with 24bpp hardware.
We should also take into consideration the question on
differing pixel packing formats when naming the
macros, but I guess a non-standard 565 encoding could
just get, say, '_nonstandard' attached to the macro name:-)
The other commonly used format IIRC, 555 can be named
consistently anyway.
> I supply some macros to convert between
> PIXELVALs and COLORVALs, and the client
> or server implementor is free to use them as
> desired.
>
> I think this design covers all your above points.
Yes, I think so too. I'll look into it as soon as I get
the chance. Thanx!
- Morten
