Checked out the feature matrix and BitmapData.merge() wasn’t listed, however the merge function appears to be implemented in the source code. Haven’t tested it yet but it seems to be supported…Is it?
It might have been added more recently than the feature matrix. Give it a try, let me know how it works for you 
Tested the merge() function but it didn’t work. Tried to use BitmapData.applyFilter() as a workaround but to no effect as well.
Turns out BitmapData.merge() works…
So here’s a bit of context. I’m targeting HTML5 and for best performance I’m manipulating BitmapData. I need to do an Alpha transition strictly between BitmapData so I don’t have the benefit of DisplayObject.alpha and I want to avoid using BitmapData.draw() since it leverages the vector renderer.
I was able to pull this off using BitmapData.colorTransform…but its very slow with large bitmaps. I turned to BitmapData.applyFilter() with the hope of applying a ColorMatrixFilter…but the method doesn’t seem to work for HTML5 targets. Eventually I managed to get an alpha transition with decent FPS via BitmapData.merge().
I know you’ve got a lot on your plate…but is there any chance you can make the BitmapData API more of a priority?
Actually, the fastest method I know of if you are targeting HTML5 canvas (which is the default method when rendering to HTML5 right now) is the canvas “drawImage” API, currently, this is used in OpenFL when you A.) use a Bitmap, B.) use bitmapData.draw, C.) use drawRect D.) use drawTiles
Any of the above APIs will perform similarly, canvas HATES individual pixels being manipulated, in general, so unless you already have to do pixel level operations, I think you’ll see faster performance doing a standard bitmap.alpha
How does BitmapData.copyPixels() stack up against BitmapData.draw() in terms of performance? I always assumed it was faster but you haven’t mentioned it in your list of preferred methods.
Oh, copyPixels. On the HTML5 backend, it tries to (if I recall) detect if it can perform a “fast” copyPixels, which (in the end of the day) is a “drawImage” call as well, so really these are all different mechanisms to hit the same API, the only real difference is that some result in an extra copy (such as an off-screen canvas for BitmapData to blit once back onto the main canvas) or not.
As much as possible, I want to eliminate different modes as “this is the ONE fastest method” and make everything as fast as possible, so it’s really about what is more convenient and fits the project better. This is why I am exciting about auto-batching with OpenFL “next” for OpenGL, because it makes a standard display list Bitmap nearly as fast as drawTiles, I want to try and extend this to other drawing as much as possible as well