nanogui: Problems building NanoGTK
Subject:
Re: [nanogui] Problems building NanoGTK
From:
Alex Holden ####@####.####
Date:
25 Jul 2002 23:05:57 -0000
Message-Id: <3D408130.50007@linuxhacker.org>
Greg Haerr wrote:
> We need to write an email to Rasterman. All he requires,
> apparently, is that the copyright notice be distributed along
> with the binaries, as well as in the documentation. This is
> equivalent to the BSD advertising clause, and is incompatible
> with the MPL. Only a small set of macros applies here,
> since all other code was written by Jordan.
Allowing code into Microwindows which requires the BSD advertising
clause would be a fundamental change to our licensing policy and could
easily scare off many commercial users.
> The current patch requires that the existing GrXXX API
> change, which breaks many existing programs.
The only thing I recall changing is that the GrDrawImage functions now
have one additional parameter, which if it is set to 0 causes them to
behave the same as previously (apart from the removal of the old ugly
transparency hack which is completely obsoleted by real alpha channel
support). If it's a big problem, rename them to GrDrawImageAlpha and add
a macro or stub function which implements the old version of the
function, setting the last parameter to 0 (which is what I did with
GrCopyArea() and GrCopyAreaAlpha()).
> In addition, a new type GR_ALPHA, is introduced, which requires
> changes to all screen drivers, adding an alpha PSD parameter.
You mean the prototype for the Blit function now has one extra parameter
that can safely be ignored if the driver doesn't support alpha channels.
I already did that for all the drivers in the distribution (and it takes
less than a minute to do it anyway).
> I'm still wrestling with the best approach here. I don't want
> to break existing programs with API extension unless absolutely
> necessary; the GrXXX routines don't need to change unless we
> require alpha channels, not just alpha blending.
The DrawImage functions don't need to change at all if you think it's
that big an issue- see above.
> like to see any pixmap be useable as an alpha channel, rather than
> introducing another drawable type. This would require that we
I'm not sure what advantage that would gain you. The alpha channel as a
seperate drawable system I implemented takes up less memory than a
pixmap of the same size on most systems (one byte per pixel), it's fast
and efficient, it's fully interoperable with the rest of the system (you
can draw on alpha channels as normal and even blit to and from them),
and all of the extra code can be compiled out in one go just by turning
off one build parameter.
--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
