On Tue, 17 Apr 2007 11:07:59 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
> > On Tue, 17 Apr 2007 10:24:36 +0200
> > Marc Weustink <[EMAIL PROTECTED]> wrote:
> >
> >> Mattias Gaertner wrote:
> >>> On Mon, 16 Apr 2007 22:46:49 +0200
> >>> Marc Weustink <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Mattias Gaertner wrote:
> >>>>> On Mon, 16 Apr 2007 11:20:55 +0200
> >>>>> Marc Weustink <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>> Continuing my TRawImageQuestion.
> >>>>>>
> >>>>>> While implementing cursors and imagelists, Paul and I start to
> >>>>>> get confused. It appears that Mask and Alpha are treated as
> >>>>>> equal while in fact they are each others inverse. (An 1 in a
> >>>>>> mask means that this part of the image is masked, not drawn,
> >>>>>> where for alpha a 1 means opaque, fully drawn)
> >>>>>>
> >>>>>> A RawImageDesription describes the RGB and Alpha parts of an
> >>>>>> image. It has also a flag that the Alpha is separate. This got
> >>>>>> introduced since traditional windows has only an image and a
> >>>>>> (1bpp) mask. When reading such image, the mask gets converted
> >>>>>> into a 1bit separate alpha.
> >>>>>>
> >>>>>> With CreateBitmapFromRawImage the fun starts. It creates a
> >>>>>> bitmap and mask handle form the rawimage. The maskhandle is
> >>>>>> created from the (separate) alpha and is in fact returning an
> >>>>>> alpha handle and not a maskhandle. On win32 this is nonsense
> >>>>>> since alpha is never separated. So I think a Maskhandle should
> >>>>>> return what it means: a handle to a Mask (and only in the case
> >>>>>> when the description had the AlphaSeparate flag).
> >>>>>>
> >>>>>> Comments ?
> >>>>> Maybe we need an enum, how to interpret the alpha value?
> >>>> I was think on that also, but somehow didn't sound right. I don't
> >>>> know exactly for all widgets, but as far as I can tell the
> >>>> separate alpha is only used for win32 1bit masks.
> >>>> If this is the case, then ignore my other mail since
> >>>> TRawImage.MaskData is indeed MaskData. But then the
> >>>> AlphaSeparate, AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder
> >>>> and AlphaByteOrder are not really Alpha, but Mask ->
> >>>> MaskSeparate (or HasMask), MaskBitsPerPixel, MaskLineEnd,
> >>>> MaskBitOrder and MaskByteOrder
> >>> True.
> >>> What do we take instead of the enum?
> >>> define: if Mask is separate, then it is opacity, otherwise
> >>> transparency?
> >> Something like that. But IMO there is no such thing as
> >> MaskIsSeparate since there won't be an included mask. HasMask is a
> >> better name I think.
> >
> > ok. Will you change it?
>
> Yes.
>
> >> And if we add MaskPrec and MaskShift: cardinal; then the Alpha
> >> definition is complete independent of a Mask definition
> >
> > Ehm, but they are not independent, are they? You can not have both!?
>
> It is a bit useless, but technically there is imo no limitation.
> And for naming it becomes clear what is meant. Mask for Mask and
> Alpha for alpha. Thinking of it, when having a MaskPrec=0 it means
> the same as HasMask=False
True.
> >> BTW, why are the xxxPrec and xxxShift defined as Cardinal and not
> >> byte ?
> >
> > Why should they?
>
> Since I think a 1000000 bit precision and a 123456789 shift won't be
> needed.
You will only save the memory by using packed or an array. With packed
we will loose speed and with an array loose readability.
> I was even considering in making them an enum, so some
> lookups could be made easier and some range checking can be avoided
I don't see, how you can avoid range checking?
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
