User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101220 Gentoo Firefox/3.6.13 Build Identifier: Profiling results are attached. In all the cases the graphics pipeline looks in the following way with some variations: 1. Perform unscaled yv12 -> r5g6b5 conversion (yv12_to_rgb565_neon) 2. Perform unscaled r5g6b5 -> a8r8g8b8 conversion (pixman_composite_src_0565_8888_asm_neon) 3. Perform nearest neighbour scaling with alpha blending of a8r8g8b8 over r5g6b5 (pixman_scaled_nearest_scanline_8888_0565_OVER_asm_neon), a variation of this is even more heavy alpha blending with a8 mask (pixman_scaled_nearest_scanline_8888_8_0565_OVER_asm_neon) 4. Somewhere around that, apparently the buffers also get moved in memory either with memcpy or simple pixman blit function (pixman_composite_src_0565_0565_asm_neon), and the buffer may get filled with some solid color (pixman_composite_src_n_0565_asm_neon) No surprise that all this graphics related activity is on the top of the profiling report, especially considering that originally tiny 320x240 video gets upscaled to something significantly much bigger (slightly less than 1280x1024) and redundant operations with this larger buffer are extremely expensive. Upscaling video for high resolutions is important for mobile devices such as Samsung Galaxy Tab (1024x600 screen) or more modern bigger tablets having 1280x800 resolution. Even current smartphones typically have at least 800x480 screen resolution. Reproducible: Always Expected Results: Using common sense, one might guess that just doing the following would have been much faster: 1. Perform unscaled yv12 -> r5g6b5 conversion (yv12_to_rgb565_neon) 2. Perform nearest neighbour scaled blit r5g6b5 -> r5g6b5 (pixman_scaled_nearest_scanline_0565_0565_SRC_asm_neon)

Closing all opened bug in a graveyard component