Hi andrew,

Ops, guess I get misundertood :), I'm sorry about that, I was talking about the delphi one itself, and that will be good if the lazarus get one that can superseed the delphi one, and that something like TImage32 with his full alpha support will be good. But since it uses a lot of asm may be hard to get something crossplatform easy with it. ps: I'm curious, what you mean with "discriminating loading" ?

Hi Andrew,

It's annoying to see that the delphi TGraphic can get displayed right on a TImage, so will be nice if the Lazarus one correct this, eg: for display right an PNG with an alpha channel. Maybe you can get some info on this on g32.org, they have an excelente TImage replacement that supports full 32 bits images at pixel level, althow porting it will may be to much hard for a first version...

just my two cents,

Connor

Marc Weustink wrote

IFAIK they use the bottom left pixel in situations where you cant tell what the transparent color is.

Yes it's the bottom left pixel. Bottom, because Windows bitmaps are stored with the scanlines running from the bottom to the top.

- Sebastian

I stand corrected.
;-)

-Tony

I would like to get TGraphic Transparency working, and since it only affects display, and that is always handled by StretchBlt in the long run, I was hoping to add it there.

However since png's, and other more advanced graphic types can have an existing transparency for instance, I would like to get the general opinion on exactly how this should be handled. With XPM's/BMP's for instance, I believe it is simply whatever is the current brush color is replaced with a transparent mask, but I am not positive as it has been awhile since I used this feature myself.

So anyway, essentially I have the following questions before I finish and commit:

1.) How should transparency be handled with graphic types that support it natively when

a.) the current graphic has such a channel
b.) it doesn't

2.) how should it be handled on types which don't support it natively

Andrew

I seem to recall that for some things (maybe I'm thinking of just a very unique situation) they would take the transparency color from the color of the top left most pixel.

-Tony

IFAIK they use the bottom left pixel in situations where you cant tell what the transparent color is.

Marc

Well, if the components aren't complete enough for you, feel free to report any missing features in TImage/TGraphic components, as if I don't know its wanted/needed I don't know to fix it. :)

Although portions of the TImage are incomplete, AFAIK the most important aspects of it are already in place, excepting proper transparency handling, which is really a TGraphic problem anyway. So I see no reason to try and rebuild it using another win32 component which may or may not have the same sort of incompatibilities after porting anyway, but I will plan on taking a look soon anyway and see if there is anything useful for lazarus in it.

As for TGraphic incompatibilities, apart from this transparency issue, the most important things that are missing are proper saving and more discriminating loading. Both of which require A.) a lot of experience/knowledge (which I don't have) or b.) a lot of research and experimentation, which I generally don't have a lot of time for, not that I don't have all sorts of grandios plans and goals mind you. :)

Andrew

ok. see this is what I wasn't sure of, obviously in the case of it having an existing transparency we should have a way of using it, but what if they have trans. turned of? should we disable both the existing and the by colour? or should it only affect by colour etc? i.e. what are the long reaching implications of having two possible transp. types at the same time or separate et al?

well the only reason this is a question is because of secondary implications of the above... considerations of consistancy etc. not really that big a deal, but for thoroughness should be mentioned.

well the question here is _what_ transparency, i.e. how is this transparency determined. If it is just a color is replaced like I think I remember, how is that colour determined? where does that colour come from? is it just a generic default? I don't think so because I remember loading different bitmaps with different colours used and Delphi almost always picked the right one. Anyway, like I say its been awhile since I had use of this so I can't remember the ins and outs of how it worked, so its hard to guess how it should work.

Andrew

I can see reason to have both transparencies applied before it's drawn. I think this is logical. Of course it's a judgment (that spelling doesn't look right, but that's what my spel cheker says) call barring previous Delphi work in this regard...

b.) it doesn't

Apply the graphic format's transparency still.

2.) how should it be handled on types which don't support it natively

Obviously apply the transparency to the graphic as it's being drawn. Well obvious to me, but I'm infamous for misunderstanding the question.

Andrew