[Papervision3D] best policy to scale up PV3D content without slowing it down?

Alan Pinstein apinstein at mac.com
Wed Jun 24 10:18:38 PDT 2009


One approach that we plan to try, but haven't yet, is to use the  
"scale" feature of Flash. You set the flash size to one amount, but  
have it draw larger. This uses HW acceleration which is fast and  
higher-quality than software scaling. Blitting in flash is horribly  
slow. For our PV3D app at full-screen, the blitting takes ~70% of the  
cpu, papervision rendering calculations only about 25%.

http://labs.adobe.com/wiki/index.php/Flash_Player:9:Update:Full-Screen_Mode_HW

We plan to try this soon, but haven't yet. I'd love to hear from you  
if you try it out.

Alan

On Jun 24, 2009, at 1:13 PM, Krobill wrote:

>
> I guess the best option would be to go for a Bitmap object whose  
> bitmapData
> is linked to the renderer. No need for a sprite, you can scale a  
> bitmap too
> and you don't get those expensive 'interaction' listeners. The
> bitmapData.draw() call and the whole 'Blitting' strategy is useless  
> most of
> the time too. When you use a Bitmap object, flash internally choose  
> between
> an internal copyPixels or Draw method to render the Bitmap whether  
> it's
> rotated/scaled or not and swap dynamically between those. At least  
> it's what
> I concluded with a serie of performance tests I did when the whole
> old-school-blitting fashion started to emerge.
>
> Alain
> -- 
> View this message in context: http://www.nabble.com/best-policy-to-scale-up-PV3D-content-without-slowing-it-down--tp24187353p24189048.html
> Sent from the Papervision3D mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org




More information about the Papervision3D mailing list