Forum Topic - Alpha blending in CWM/OpenKODE: (6 Items)
   
Alpha blending in CWM/OpenKODE  
Hi,

We are using CM for our HMI and have major performance issues with the screen update.  As such I am hoping that you 
could offer some suggestions.  For reference the target micro is the i.MX31 and the displayed resolution is 800x480, 
RGB565.

Our HMI screens consist of many alpha-blended layers, with separate layers for the background, frames, each button, each
 icon, text fields etc.  The text is rendered while the remainder of the screen elements are PNG images (i.e we have a 
background image with an overlaying frame image with overlaying button images etc).

Using a kernel trace we have observed the screen rendering times alone are around 700-800ms (combine this with the apps 
processing time, retrieval of PNG's from NAND etc and we're talking in the order of seconds for some screens).  

We tried (out of interest) to render a solid-coloured rectangle of size 800x480 to the display.  With alpha-blending 
turned off it took around 20ms.  With alpha-blending turned on the rendering time was 500ms.  Considering it was only a 
single composite layer and therefore no alpha-blending was required to be calculated in this circumstance, should it 
take so much longer to render?

Also, how does the CM layering work internally? i.e. is it more efficient to have the screen split into many smaller 
layers/elements so smaller areas are updated, or is it more efficient to minimise the amount of layers used and rather 
have larger-sized individual layers?  

Some parts of our screen can be up to 4 or 5 layers deep, however most/all layers have either full or no transparency. 
Since effectively only the topmost layer is visible, are all the below layers still calculated/alpha-blended?

Are any of the settings in winmgr.conf worth changing?

Cheers,
Radek.
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  
Thanks Eric,

The contents of our winmgr.conf file are as follows:

begin globals
 input = all
end globals

begin display
 cursor = sw-arrow
 begin plane
  egl-config = auto
 end plane
end display

I have attached the ouptut of io-winmgr -d.

Cheers,
Radek.
Attachment: Text io-winmgr.output 38.84 KB
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.
Re: Alpha blending in CWM/OpenKODE  
Thanks alot for your help Etienne, based on your comments as a starting point we'll try reducing the amount of layers to
 see what improvements can be had.  You mention that a future CM release will be using dirtied areas instead, do you 
know how far away the release is?

Best regards,
Radek
Re: Alpha blending in CWM/OpenKODE  
It will be in the next release, but I cannot say when that will be.