PROBLEM DESCRIPTION
Customer wants to get views with a smooth drop shadow. Customer wants to add a png image with a pattern, so that one will appear under the view.
EXTRA INFO
Right now, they are using a workaround similar to this one:
//Create a view container
var container = Ti.UI.createView({
width:200,
height:200,
top:10,
left:10
});
//Create a drop shadow view
var shadow = Ti.UI.createView({
width:195,
height:195,
right:0,
bottom:0,
borderRadius:5,
opacity:0.5,
backgroundColor:"#787878"
});
container.add(shadow);
//Create a view for our content
var content = Ti.UI.createView({
width:195,
height:195,
top:0,
left:0,
borderRadius:5,
backgroundColor:"#cdcdcd"
});
content.add(Ti.UI.createLabel({
text:"Here is some content",
textAlign:"center",
color:"#000"
}));
container.add(content);
//Open an application window
var win = Ti.UI.createWindow({
backgroundColor:"#fff"
});
win.add(container);
win.open();
Instead of adding the container and the shadow, customer wants to have a special view with where you can set the png for the shadow, and a size for it.
The goal is having something like the attachment, but with any png.
We should get clarity on what, exactly, the customer needs. Because dynamic shadow-making like this gets expensive (read: Laggy on phones) VERY quickly. If he needs shadows of images he knows he'll be using, he really should prebake them into images instead. Even on pure-native solutions are shadows and gradients rarely computed, for exactly the reason of speed, performance, and memory. All of the gelcap-style translucent buttons, table row gradients, and rounded text entry borders Apple uses are prebaked png files, NOT computed at runtime.
Depending on usage, image size, etc, we're talking visible performance lag. In terms of memory, it means the difference between: * Load image, which may be memory mapped. * Create a new bitmap in memory. * Transfer image in memory, possibly only the alpha channel at best case scenario. * If they want it to be key-color based, this requires another pass over every pixel * If they want the shadow to be blurred, this requires significant processing. * Draw shadow image (probably another layer to maintain) offset. * Draw original image onscreen. * Repeat whenever the image changes, possibly. Versus pre-baking: * Load image, which may be memory mapped. * Draw image onscreen. It is very likely that this will be the difference between a table view that scrolls smooth, and a table view that badly jitters. The important take-away is that pre-baking gives you things that any implementation here would not provide outright. For example, pre-baking means you can have the shadow however you choose, complete with blurring and soft alphas, with NO performance hit.
Moving it out of current sprint as it should be done at the application level.
Proposing we mark this invalid. The customer has a better option, thus removing the need.
Closing ticket as invalid.