Ken McIvor wrote:
> I think they added preliminary support for alpha channels in 2.5, in the
> form of wx.Image.HasAlpha().
right, but it uses the old 24 bit RGB buffer, and separate Alpha buffer,
it's kind of tacked on, rather than native.
> My beef is that you have to convert
> everything to a wx.Bitmap before you can do anything useful with it.
And that DCs don't support alpha, even though the underlying device
often does. This has been discuses a lot, but no one has done much about
it yet -- wxTNG will have something better, but who knows how far out
that is?
> As near as I can tell, the primary slowdown at this point is the way
> wxWidgets distinguishes from RGB image data (wx.Image) as opposed to
> displayed image data (wx.Bitmap). Right now you cannot draw a wx.Image
> without first converting it into a wx.Bitmap, nor can you use a MemoryDC
> to blit or otherwise munge a wx.Image directly. My impression is that
> this made sense when wxWindows was getting started (Win16 and Motif),
> but is more of an artificial distinction at this point.
a wxBitmap is the same format as the native rendering system. While most
systems use 24b RGB (or 32b RGBA), people can still run displays at
16bpp or whatever, so it's still needed. Also, I wouldn't be surprised
if some less common systems use ARGB or something else weird.
> I don't think we're going to be able to get performance similar to that
> of the accelerator using straight Python code
But whether it's Python or C++, you still need to do the Image->Bitmap
conversion -- so if we can get rid of the data copying from Agg buffer
to wxImage in Python, we don't need C++.
> unless something changes
> in the wxWidgets' Image/Bitmap/MemoryDC department.
And it has. For wxPython 2.7 (and now in CVS) there are methods for
dumping 32 bit RGBA data directly into a wxBitmap with no copying, if
the data source is a Python Buffer object. I think I posted a note about
this here yesterday.
> I'd love to be proven wrong! If you're interested in the gory details,
> you should check out the pure-Python implementation of the image
> conversion functions, at the end of `backend_wxagg.py'.
I did, and I suggested some improvements a couple messages back. To
really get it to work, the 24bit RGB Agg buffer needs to be a Python
Buffer object -- is it now? I'm sorry I don't have the time to mess with
this now -- maybe some day.
>> I do have one question -- does the agg back-end really need to use an
>> alpha channel for it's buffer? Isn't it the whole image anyway? What
>> is is it going to get blended with?
>
> I don't know enough about Agg to venture an educated guess. My
> un-educated guess is that there's an RGBA buffer to support alpha in the
> drawing operations... how can Agg alpha-composite new pixels into the
> buffer when you draw something, unless you know the alpha values of the
> existing pixels?
You can alpha composite into a non-alpha background. You just lose the
alpha there, so that the background couldn't be alpha-composited onto
anything else -- but does it ever need to be?
However, there is something to be said for just using alpha everywhere,
and as we'll soon be able to dump RGBA data straight into a wx.Bitmap,
this should work great.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
