|
Re: Alpha blending in CWM/OpenKODE
|
02/04/2010 1:41 AM
post46508
|
Re: Alpha blending in CWM/OpenKODE
Radek,
I just noticed your post here. While I can't address your question directly as I'm not 100% sure on the answer, I
thought I'd chime in on what additional information you might provide so that the question can be addressed.
You might want to include the winmgr.conf file that you are using as I'm sure it will be needed to address your question
.
I'm also guessing it would be useful to do a 'io-winmgr -d' while your application(s) is/are running and provide the
output of that so that the internal configuration of that module can be known.
http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/io-winmgr.html
Regards,
Eric
|
|
|
|
Re: Alpha blending in CWM/OpenKODE
|
02/04/2010 9:03 AM
post46528
|
Re: Alpha blending in CWM/OpenKODE
This is a pretty lengthy question, so I hope you don't mind if we answer indivdual elements over a couple of posts...
As to whether rendering time should increase when alpha blending is enabled, even if the contents are fully opaque, the
answer is yes, it is quite possible. The composition manager does not look at pixel values to determine areas with
transparency, and there are no transparency hints yet. Therefore, compositing in this case will be performed with per-
pixel alpha blending enabled. The graphics accelerator may be able to optimize this operation by skipping reading the
destination buffer when the source alpha value is 255, but that is up to the hardware. The only type of blending that
allows compositing optimizations is global alpha with an opaque value (255) with per-pixel alpha disabled expicitly or
implicitly (no alpha channel).
The way compositing works is quite straightforward. Any time a window changes, all visible windows and any background
that intersect with that window are composited back to front. If a window is opaque, no window beneath it and no
background will intersect. However, there could still be semi-transparent windows on top of it that will have to be re-
composited too. Future releases will apply the same rules, but using dirtied areas instead of the full window. Until
then, it is clear that the best approach to minimize updates is to minimize the number of overlapping semi-transparent
layers. One way to do this would be to flatten static content, i.e. blend static images in a pre-processing stage, to
reduce the number of layers. For content that is a little more dynamic, one could use a rendering API such as OpenGL ES,
OpenVG, or even use software, to flatten some layers. What's best depends on what's static and what changes a lot, the
number of layers, the size of the transparent areas, how they overlaps, and so on.
|
|
|