nanogui: Usage of Alpha Transparency in PNG Files


Previous by date: 13 Mar 2009 02:22:36 -0000 Getting started - help!, Robert S. Grimes
Next by date: 13 Mar 2009 02:22:36 -0000 Ways to speed up a simple application?, Ricardo P. Jasinski
Previous in thread: 13 Mar 2009 02:22:36 -0000 Re: Usage of Alpha Transparency in PNG Files, Vladimir Ananiev
Next in thread: 13 Mar 2009 02:22:36 -0000 Re: Usage of Alpha Transparency in PNG Files, Marius Zwicker

Subject: Re: [nanogui] Usage of Alpha Transparency in PNG Files
From: "Greg Haerr" ####@####.####
Date: 13 Mar 2009 02:22:36 -0000
Message-Id: <0bc101c9a382$638498c0$6864a8c0@winXP>

: I'm trying to use a PNG File with Alpha Channel via  
: GrDrawImageFromFile to realize shadows and certain design elements. As  
: this seemed not to be implemented in the 0.91 release of nano-X I  
: already downloaded and built the latest CVS version. According to this  
: mailing list the png-transparency issue should be fixed by now.  
: Unfortunately this is not the case (?). When trying the latest  
: development version, it leaves out 100% transparent parts (as  
: expected) but draws parts with less transparency (e.g. 50%) as pure  
: black areas and not semi transparent.

AFAIK, all issues related to the original transparency
bug have long been committed to CVS.  The original issue
related to having a single transparency color (transcolor)
for GIF images.  Pixels with that matched this color would
not be drawn.  The problem resulted from an accepted
contribution that added alpha-channel support.  By
default, the alpha channel is 255, and the color white
(255,255,255) happened to match the default 
no-transparency value of -1.

There were then some other patches (all in CVS)
to make sure that the other image decoders worked
with the new scheme.

However, your problem is one of drawing alpha channels,
which is current supported via a contribution that only
provided alpha channel drivers for certain pixel bpp.

This entire issue brought about the problem of re-architecting
the way(s) nano-X goes about drawing images, originally
using the screen Blit entry point, and now requiring the identical
functionality DrawArea entry point. The original Blit wasn't
required, and the system would draw per-pixel, so that
simple screen drivers could be implemented quickly.  Of course,
this doesn't work well with modern day requirements for
fast blitting with operators and alpha channels.

A quick fix might be to try Vladimir's version, which might
implement the GdBlit engine function differently, calling
the DrawArea function which works with alpha channels.
I don't have access to the source right here, so I can't
comment fully.  Should this work, I or him can add that change
to CVS.

Regards,

Greg

Previous by date: 13 Mar 2009 02:22:36 -0000 Getting started - help!, Robert S. Grimes
Next by date: 13 Mar 2009 02:22:36 -0000 Ways to speed up a simple application?, Ricardo P. Jasinski
Previous in thread: 13 Mar 2009 02:22:36 -0000 Re: Usage of Alpha Transparency in PNG Files, Vladimir Ananiev
Next in thread: 13 Mar 2009 02:22:36 -0000 Re: Usage of Alpha Transparency in PNG Files, Marius Zwicker


Powered by ezmlm-browse 0.20.