Faster JPEG Encoding with Flash Player 10

When Flash Player 10 was released, you heard about this new Vector class, if you are not using it already in your FP10 projects, well you definitely should. When talking with some guys at DotEmu, they confessed me that their whole emulation engine (ported from Java to AS3) which was able to emulate any kind of 8bit and 16bit console was not fast enough to be used in production in Flash Player 9.
When Flash Player 10 was released, they switched from Array to Vectors and realized that their engine was running much faster thanks to methods like BitmapData.setVector() and the Vector class.

After a few days I realised that the JPEG encoding class used in the corelib package was using a lot of Arrays and could benefit from the Vector class and I was pretty sure some tricky optimization could be done. That's what I did and modified its code to make it faster, I was happy to see that the new version was around 2.5 times faster (on my machine). Now more than 4 times.

Here is a little demo (encoding a 2880*2880 BitmapData) showing the difference between the old version and the new one, if you could post your results through the comments that would be interesting :

A Flash animation should have appeared here, but it seems that your browser has an older version of the Flash Player or it is not installed at all. Please, install the last release of the Flash Player now, then reload this page.

So what did I do ?

  • I used bitwise operators as much as possible.
  • I replaced all Arrays with fixed length Vectors.
  • I used pre-incrementation rather than post-incrementation (thanks Joa for this one ;)).
  • I casted to int almost all my Vector indices access.
  • Other minor stuff you always do to optimize your code :)

The encoding process could be even faster thanks to Pixel Bender for the RGB to YUV process, unfortunately as you may know loops are forbidden when Pixel Bender jam is running in the Flash Player. Pre-processed the RGB to YUV with a simple ColorMatrixFilter or Pixel Bender, this didn't bring performance improvements. I am sure this can still be optimized if ported to haXe for instance, if some of you are using an asynchronous version of the original version, you can integrate the optimization from this one.

Download it here.

Update : 05/24/09 : New version with tiny additions, which should make it run a little bit faster.
Update : 05/26/09 : New version with tiny additions, a little bit faster. (Thanks Joa and Kyle for your tips)
Update : 05/27/09 : New version with some unuseful code removed.
Update : 05/30/09 : New version with tiny additions, a little bit faster again. (Thanks tst)

Comments (186)

  1. Mark Cooke wrote:

    I’m on an iMac with a 3.06 GHz Core 2 Duo.

    Original corelib version: 14370 ms
    Optimized version: 6457 ms

    Note quite 2.5x for me but still easily over 2x.

    Friday, May 22, 2009 at 5:36 am #
  2. subb wrote:

    original : 12593ms
    optimized : 5073ms

    Well, that’s pretty good. :)

    Friday, May 22, 2009 at 5:37 am #
  3. andy wrote:

    original corelib version : 21911ms
    optimized version : 7053ms


    Friday, May 22, 2009 at 5:46 am #
  4. Luchyx wrote:

    XP – dual core 1 GB ram:
    corelib = 26277ms
    optimized = 9674ms

    Me notebook doesn’t freeze with the optimized version.
    Excellent work bro!

    Friday, May 22, 2009 at 7:18 am #
  5. Hey Thibault, nice work!

    You are right just about 2.x faster, my times were:
    original corelib: 14145ms
    optimized: 5915ms

    I’m working on a couple project that leverage the corelib JPG and PNG encoders, so this is a real treat! Thanks!

    Will have to take a look at the PNG encoder and see how it might benefit from Vectors.

    Keep up the great work!

    Friday, May 22, 2009 at 8:11 am #
  6. NICE! Posting results:

    Original: 14701 ms
    Optimized: 5746 ms

    Impressive improvement. I’ll have to look into these fancy Vector things ;)

    Friday, May 22, 2009 at 8:12 am #
  7. Actually – it looks like the PNG encoder would be a bit tricker to optimize as it doesn’t appear to rely as heavily on lookup tables of data contained in arrays like the JPG encoder does – but still worth a look. :)

    Friday, May 22, 2009 at 8:13 am #
  8. katopz wrote:

    quad core (via my AIR Browser :P) 16413ms vs 5850ms, indeed!

    Friday, May 22, 2009 at 8:17 am #
  9. dogdoy wrote:

    Mac mini core2duo 1.83GHz
    19220ms / 6626ms
    3 times faster.

    Friday, May 22, 2009 at 8:31 am #
  10. davr wrote:

    14244ms vs 4941ms…pretty nice. Does it make any difference that the source image is 90% solid white?

    Got a quad here as well…too bad flash can’t use it. Though I heard PB can use multiple cores, so if we could harness that, I imagine even greater speedups possible.

    Friday, May 22, 2009 at 8:32 am #
  11. Core 2 Duo 2.6 Ghz:
    Original: 16669ms
    Optimized: 6517ms

    Much improved. :-)

    Friday, May 22, 2009 at 8:33 am #
  12. Original Version: 16313ms
    Optimized Version: 5640ms

    That’s in Firefox 3.0.10 in Mac OS X 10.5.7 on a 2GHz Intel Core 2 Duo MacBook with 2GB of PC3-8500 DDR3.

    Any particular reason you didn’t make the result text selectable? That would be a nice minor improvement. So would adding title elements to any icons without captions (especially ambiguous two-image icons such as icon-author.png).

    Friday, May 22, 2009 at 8:34 am #
  13. Alan wrote:


    Friday, May 22, 2009 at 8:35 am #
  14. Misterhee wrote:

    Core 2 Duo E6650 @ 2.33 w/ 4Gb RAM on Vista 32:

    18861 ms vs. 7457 ms !

    Friday, May 22, 2009 at 8:36 am #
  15. julien wrote:

    original : 27158ms
    optimized : 11976ms

    Friday, May 22, 2009 at 8:55 am #
  16. cosmoz wrote:

    awesome!!! tested on iMac version 10.5.6, Safari 4 got result 18093ms and 6084ms : 3 times faster!! Do you have a plan for PNGEncoder too? :)

    Friday, May 22, 2009 at 8:57 am #
  17. Misterhee wrote:

    Oh, I forgot to ask – Do you feel like updating the PNNGEncoder class as well? That would be awesome…

    Friday, May 22, 2009 at 9:01 am #
  18. Jonathan wrote:

    17071ms vs 5287ms on my trusty ol dual core macbook pro. Very cool!

    Friday, May 22, 2009 at 9:07 am #
  19. Wai Lam wrote:

    original : 21824ms
    optimized : 9870ms

    MacMini Core2Duo 2.0G

    Friday, May 22, 2009 at 9:10 am #
  20. sheryl wrote:

    original: 22358
    optimised: 7907

    very nice.

    Friday, May 22, 2009 at 9:11 am #
  21. ruffy wrote:

    original: 17986
    optimized: 7326

    quad core.

    by the way: * 0.01 instead of / 100 could boost your code a little more.

    Friday, May 22, 2009 at 9:19 am #
  22. mike wrote:

    14303ms vs 4861ms

    Friday, May 22, 2009 at 9:41 am #
  23. Eugene wrote:

    I still prefer async encoding ;)
    But this one is realy good adition

    Friday, May 22, 2009 at 10:03 am #
  24. Hi Thibaullt,
    On my PPC G5 :
    original : safari beta crash
    optimized : 20265

    Friday, May 22, 2009 at 10:17 am #
  25. JeanJack wrote:


    original : 18243ms
    optimized : 7980ms

    Friday, May 22, 2009 at 10:30 am #
  26. xitij2000 wrote:

    original: 29912
    optimized: 10347
    awesome indeed…

    Friday, May 22, 2009 at 10:31 am #
  27. taalto wrote:

    original : 18036ms
    optimized : 7270ms


    Good job!

    Friday, May 22, 2009 at 10:43 am #
  28. chiu wrote:

    original : 12889ms
    optimized : 4292ms

    Friday, May 22, 2009 at 10:47 am #
  29. oskitar wrote:

    FF3 & Player
    22711 vs 9945 ms
    on my MacBook 2GHz Intel Core 2 Duo, 2GB Ram

    Impressive work! thanks for sharing.

    Friday, May 22, 2009 at 10:49 am #
  30. Original: 15968ms
    Optimized: 6339ms

    Nice work!

    Friday, May 22, 2009 at 11:03 am #
  31. INS wrote:

    Original 19751 ms
    optimized 8121 ms
    2.4 times faster

    Friday, May 22, 2009 at 11:22 am #
  32. Adam wrote:

    20387ms down to 8637ms pretty sweet!

    Friday, May 22, 2009 at 11:23 am #
  33. vitaLee wrote:

    AMD Athlon 64×2 Dual Core 2.19Ghz
    2G ram – 20523 : 6615.
    good job!!!

    Friday, May 22, 2009 at 11:28 am #
  34. Mark wrote:

    13641 vs 4327

    Very nice optimization. I didn’t know vectors are that much faster.. Could you do this trick for the PNG encoder too?

    Friday, May 22, 2009 at 11:54 am #
  35. James wrote:

    Intel Core Duo 2.26ghz,
    4G RAM,


    Got to give this a try in ImageSizer now… :)

    Friday, May 22, 2009 at 12:10 pm #
  36. Great Job! About the YUV conversion – I wonder why you do not use a simple ColorMatrix filter for that. YUV is the same as YCbCr and the matrix for that is: Y’ = 16 + ( 65.481 * R’ + 128.553 * G’ + 24.966 * B’)
    Cb = 128 + (-37.797 * R’ – 74.203 * G’ + 112.0 * B’)
    Cr = 128 + (112.0 * R’ – 93.786 * G’ – 18.214 * B’)

    Friday, May 22, 2009 at 12:25 pm #
  37. Thibault Imbert wrote:

    Hi ruffy,

    Nice one, I added it ;)


    Friday, May 22, 2009 at 12:36 pm #
  38. Thibault Imbert wrote:

    Hi Mario,

    Yes! A simple ColorMatrixFilter, good idea, I will make some tests today and let you know :)

    Thanks ;)

    Friday, May 22, 2009 at 12:44 pm #
  39. AZ wrote:


    But I can not do anything when it works.

    Async encoding may be more better:

    Friday, May 22, 2009 at 12:44 pm #
  40. Much faster…

    original – 12432
    optimised – 4006
    2.83GHz Core2 Quad

    Friday, May 22, 2009 at 1:02 pm #
  41. PEZ wrote:

    13876ms -> 4764ms on my Macbook Pro 15 incher.

    Good work and thanks for sharing!

    Friday, May 22, 2009 at 1:24 pm #
  42. peruho wrote:

    MacBook Pro Intel Core 2 Duo 2.4 Ghz 2Gb Ram on a Firefox 3.0.1

    3.2 times faster!!

    Friday, May 22, 2009 at 1:28 pm #
  43. Peter wrote:

    original: 21105ms
    optimized: 8826ms

    MBP 2.4GHZ 2GB RAM

    Friday, May 22, 2009 at 1:31 pm #
  44. hugo wrote:

    corelib version: 21732 ms
    optimized: 9547 ms

    Friday, May 22, 2009 at 1:33 pm #
  45. unclepaulie wrote:

    I’m on an Intel Q9550 (Quad core) 2.83GHz with 4GB RAM

    corelib: 12200ms
    optimized: 4248ms

    Friday, May 22, 2009 at 1:33 pm #
  46. Thibault Imbert wrote:

    Thanks for all your feedbacks, it seems like some of you have it running more than 3 times faster, nice!


    Friday, May 22, 2009 at 1:36 pm #
  47. Kyle Lu wrote:

    I compared two jpeg files generated by two encoders, and the faster’s is 1 byte less than the corelib’s(near the end of file).

    Friday, May 22, 2009 at 1:41 pm #
  48. Great, I was annoyed with the speed of the old JPEGEncoder, so this is a lifesaver! Thanks! :)

    Friday, May 22, 2009 at 1:41 pm #
  49. Kyle Lu wrote:

    Sorry, but there is flaw in the faster JPEGEncoder.
    Comparing the source file, here is the flaw coming in:
    fillbits.len = ++bytepos;
    fillbits.val = (1<<(bytepos+1))-1;
    it should be:
    fillbits.len = ++bytepos;
    fillbits.val = (1<<(bytepos))-1;
    Thank you for the encoder!

    Friday, May 22, 2009 at 1:48 pm #
  50. I’m on Windows XP, Pentium 4, 3GHz, 3GB of RAM.

    Coreliob version: 25897ms
    Optimized version: 8665ms

    Friday, May 22, 2009 at 1:51 pm #
  51. Dee wrote:

    Original corelib version: 18693 ms
    Optimized version: 8448 ms

    Friday, May 22, 2009 at 1:53 pm #
  52. Thibault Imbert wrote:

    Thanks a lot Kyle, byte flaw fixed ;)


    Friday, May 22, 2009 at 2:29 pm #
  53. Pedram wrote:

    default: 14944
    optimized: 4820

    3.1 faster


    Friday, May 22, 2009 at 2:32 pm #
  54. Blue112 wrote:

    33107 vs 12102.

    Kinda good :D

    Friday, May 22, 2009 at 2:51 pm #
  55. ryan wrote:



    Friday, May 22, 2009 at 3:08 pm #
  56. Swingpants wrote:

    6400 @ 2.13GHz
    1.97GB Ram
    Intel(R) Core 2

    Very pedestrian work computer.

    14487ms vs 8068ms
    1.8 times faster

    Great work.

    Friday, May 22, 2009 at 4:56 pm #
  57. Mem's wrote:

    48093ms vs. 17735ms

    Xeon 3GHz
    With lot of apps launched in same time.

    Friday, May 22, 2009 at 5:09 pm #
  58. Exey wrote:

    AMD Athlon 64 X2 Dual 2.71Ghz, 2GB RAM

    22448 ms
    8091 ms

    22448/8091 ≈ 2.77

    Friday, May 22, 2009 at 6:43 pm #
  59. I’m on an iMac OSX 10.5.7 with a 3.06 GHz Core 2 Duo, safari 4
    Original corelib version: 14507 ms
    Optimized version: 6222 ms
    2.33x for me
    Nice work

    Friday, May 22, 2009 at 7:18 pm #
  60. Paulo wrote:

    Mac OS X 10.5.7 (Safari 4)
    2.6GHz Intel Core 2 Duo

    Original: 16944 ms
    Optimized: 7880 ms

    Very cool!

    Friday, May 22, 2009 at 8:05 pm #
  61. malczak wrote:

    this example is excellent, I have been recently working on an alchemy libjpeg port. It runs fast and produces smaller jpeg files and is asynchronous ….

    I have published quick comparison at :

    Source code is also available

    Friday, May 22, 2009 at 8:42 pm #
  62. gropapa wrote:

    j ai rien compris au code… en tout cas ca a l air de bien marcher :)
    “on mérite pas!!!…on est tout p’tit”

    Friday, May 22, 2009 at 9:45 pm #
  63. wrote:

    hmmmm your post is interesting, but there’s a much faster way to do it, which is to use Alchemy to compiple the IJG JPEG Codec (or libjpeg) into an AS3 library and use its encoding feature. On my machine, your improved algorithm took 10seconds to encode the jpeg, but with Alchemy i can finish encoding a similar sized 8MP image in less than 4 seconds due to the way Alchemy leverages gcc compiler’s highly optimized code generation. Furthermore, libjpeg has other nice and handy features such as preserving EXIF metadata tags and image decoding.

    Friday, May 22, 2009 at 10:11 pm #
  64. Thibault Imbert wrote:

    Hi malczak,

    Very nice use of Alchemy! ShaderJob makes things easier for an asynchronous behavior ;)

    Hi aaron,

    Yes, as malczak posted, you can make it even faster with Alchemy thanks to libjpeg for instance, but the idea behind this demo was more to show how the Vector class and simple code optimizations in AS3 could make things run faster. libjpeg is very nice, I am pretty sure it can also be optimized :)



    Saturday, May 23, 2009 at 12:12 am #
  65. Ian McLean wrote:

    Awesome work Thibault.

    I just made an asynchronous version as well.

    Saturday, May 23, 2009 at 12:16 am #
  66. Tek wrote:

    Amazing Thibault !

    13888ms vs 5198ms

    I can’t even find any new trick to accelerate it a little.

    I hope we will have this as an official optimized version of JPEGEncoder in Flex SDK.

    Do you think you could rework it to make it work both synchronous and asynchronous by just calling the right method ?

    Saturday, May 23, 2009 at 1:36 am #
  67. sam wrote:

    Could someone elabourate on how pre-incrementation is faster than post-incrementation?

    Saturday, May 23, 2009 at 2:02 am #
  68. maliboo wrote:

    array: 22968ms
    vector: 7967ms

    Saturday, May 23, 2009 at 1:15 pm #
  69. Thibault Imbert wrote:

    Hi Mark,

    The PNG encoder could also be optimized but as Robert said, the JPEG algorithm does not rely on lookup tables. So any optimization would not bring that much performance improvements.


    Saturday, May 23, 2009 at 2:52 pm #
  70. malczak wrote:

    @Thibault, @Mark
    In my personal opinion, compression and related can be done with Alchemy ports particularly when working in AIR env. produced swc libs are quite large, and need more tests, but a results are a much better. What do You think about it ?

    Saturday, May 23, 2009 at 4:29 pm #
  71. Niklas wrote:

    Orig: 23669
    Opt: 7151

    3.3x faster!

    Mac OS X (leopard), Firefox.

    Saturday, May 23, 2009 at 5:03 pm #
  72. Thibault Imbert wrote:

    Hi malczak,

    Alchemy is a great project which allows us to check how AS3 and the compiler can be optimized. I wish we could have such optimizations in forthcoming AS3 compilers. For the moment I see Alchemy as a wonderful field of play for that.

    Talking about AIR, yes, Alchemy SWC are a bit large, and yes this would suit better with AIR, but honestly I think that for everyday uses with “normal” images to compress, a simple asynchronous version of the version I posted would be fine. I think Alchemy could be interesting for heavier process like runtime sound or video compression. Well, so many things to experiment ! :)

    Saturday, May 23, 2009 at 5:31 pm #
  73. Saku wrote:

    16712ms vs 5501ms
    - Dual core Opteron 185
    - 32bit Vista.

    Nice work!

    Saturday, May 23, 2009 at 6:10 pm #
  74. Thibault Imbert wrote:

    Hi Mario,

    I finally pre-processed the RGB to YUV with some Pixel Bender but it does not really bring some performance improvements. I am still investigating, I let you know :)

    Saturday, May 23, 2009 at 9:03 pm #
  75. AWESOME!
    Now someone just needs to make an asynchronous version…

    Saturday, May 23, 2009 at 11:48 pm #
  76. 2.8x faster (Lenovo wrote:

    2.8x faster (Lenovo 3000 N200)

    Sunday, May 24, 2009 at 8:37 pm #
  77. lua wrote:

    Is there a plan of PNGEncoder?

    Monday, May 25, 2009 at 5:31 am #
  78. Inter Core 2 Duo 2.53ghz x 2
    3.25ghz RAM

    Encoding time (original): 16268ms
    Encoding time (optimized): 6281ms

    Impressive improvement.

    Tuesday, May 26, 2009 at 12:02 am #
  79. Kyle Lu wrote:

    I’ve modified the com.adobe.images.JPGEncoder according to IJG’s jpeglib,
    using ColorMatrixFilter to do RGB2YUV and added two interger fDCT method. The result is 20% to 35% gain on performance!
    Hope it could be faster with Vector!

    Tuesday, May 26, 2009 at 11:33 am #
  80. Thibault Imbert wrote:

    Hi Kyle,

    Nice! But the link you posted needs authentification (user & password) ;)


    Tuesday, May 26, 2009 at 11:40 am #
  81. Kyle Lu wrote:

    Sorry, that svn repo is not public.
    demo source:

    Tuesday, May 26, 2009 at 12:00 pm #
  82. Thibault Imbert wrote:

    Hi Kyle,

    Very interesting approach with the two integer fDCT methods. An interesting thing, during my tests, I noticed that encoding time was faster without any RGB to YUV pre-processing through ColorMatrixFilter and even with Pixel Bender.

    Do you allow me to integrate those two fDCT methods and see if it runs even faster with Vectors ?



    Tuesday, May 26, 2009 at 12:48 pm #
  83. malczak wrote:

    hi, I’ve just done some more test with Kyle’s class. here are my results for 1024×1024 bitmapData:

    orginal JPGEncoder : 6715ms encoder : 4262ms
    Kyle’s encoder : 6358ms
    Alchemy async encoder : 1711ms
    Alchemy sync encoder : 326ms

    In both Alchemy runsm, files produced were about ~30% smaller.

    Tuesday, May 26, 2009 at 6:14 pm #
  84. Thibault Imbert wrote:

    Hi malczak,

    Thanks for the bench, that’s interesting. I did some minor optimizations in the last version I just uploaded an hour ago.

    Can you try it and tell me if you some improvements ?



    Tuesday, May 26, 2009 at 6:29 pm #
  85. Kyle Lu wrote:

    The code was from IJG’s jpeglib, no Legal Issues I guess ;)
    I’m still working on flash player 9 platform, no plan for fp10 yet. So it would be great if you make use of the code.
    Sounds not so cheering to me :(
    I’m kind of stuck onto fp9, Alchemy is not my choice.

    Tuesday, May 26, 2009 at 6:34 pm #
  86. malczak wrote:

    here is result with new version of Yours class (single run) encoder : 3417ms

    no change is size difference

    Tuesday, May 26, 2009 at 6:37 pm #
  87. Thibault Imbert wrote:

    Hi malczak,

    Thanks, little improvement here that’s cool. Damn, too hard to fight against Alchemy ;)

    I think I can reach the alchemy async speed, but async is far :)


    Tuesday, May 26, 2009 at 6:42 pm #
  88. Kyle Lu wrote:

    About the file size difference, it could be result of optimal Huffman coding tables, which costs more calculation. Non-Alchemy encoders would not take that burden.

    Tuesday, May 26, 2009 at 7:00 pm #
  89. malczak wrote:

    async Alchemy version can still be tuned :) it can run faster, but then it may cause flash player blocking
    this is yet another advantage of Alchemy port

    Tuesday, May 26, 2009 at 7:32 pm #
  90. Core 2 Duo 2.4, 3GB, Vista
    Great job, guys!

    Tuesday, May 26, 2009 at 7:43 pm #
  91. 15500 vs 3700 on a 2,93GHz iMac running a Debug FlashPlayer 10,0,22,87 … that’s over 4 times faster now!

    “chapeau !” :)

    I think you can stop optimizing the JPEG encoder and move on to the PNG encoder!

    (!) seriously, optimize the PNG encoder next, please ^^

    Tuesday, May 26, 2009 at 11:44 pm #
  92. Thibault Imbert wrote:

    Hi Patrick,

    Wow nice results, yes it seems that some people are having a 4 times faster encoding now.

    I am still optimizing some parts, I think I can bring it around 2000ms.

    I will definitely take a look at the PNG encoder.


    Tuesday, May 26, 2009 at 11:58 pm #
  93. malczak wrote:

    hi, Im still on and testing :) encoder : 3352ms
    alchemy async : 1855ms
    alchemy sync : 264ms

    Wednesday, May 27, 2009 at 2:51 am #
  94. thibaud wrote:

    Core2 Quad Q9450 (2.66Ghz):

    Wednesday, May 27, 2009 at 5:11 am #
  95. Kyle Lu wrote:

    Hi Thibault,
    I was wondering while reading your encoder:
    1. There’s a lot of “int()” in the code.
    But by decompile the swf you always see a “convert_i” instruction before assigning to a int, “int()” would insert a “callproperty public::int, 1″ before “convert_i”, which would be redundancy in my opinion.

    2. You used “const” instead of direct constants.
    “const” was compiled to local variable (write protect must happend during compile time), so “const” substituting constants cause “getlocal” instructions substituting “pushbyte” instructions. Is that faster?

    3. Why the buffer-and-copy-while-init things for Vector lists?

    Wednesday, May 27, 2009 at 11:48 am #
  96. Thibault Imbert wrote:

    Hi Kyle,

    1. I thought it would be redundant also. In fact I removed the explicit int() casting when only accessing Vector indices without any mathematical operations done. If I remove the explicit casting when doing mathematical operations encoding is much slower.

    2. To be honest, I used const here cause it made sense to use them, but it does not really bring huge performance improvements, some tiny ms won only.

    3. When using the Vector global function to convert an Array to Vector you cannot specify that the new vector just created has a fixed length. That’s the reason why I created buffers to fill fixed length Vectors, but what I can do is just set the fixed property of the newly created vectors to true. That’s what I just added :) Thanks for noticing this silly thing :)


    Wednesday, May 27, 2009 at 8:42 pm #
  97. Kyle Lu wrote:

    Thanks, Thibault.
    The int() worked great!

    And believe it or not, BitString should be optimized too!

    Thursday, May 28, 2009 at 7:09 pm #
  98. tst wrote:


    I have optimized your version from 05/27/09 – it’s about 25% faster. Here is the code: and here is the diff:

    Saturday, May 30, 2009 at 12:36 am #
  99. Thibault Imbert wrote:

    Hi tst,

    Good optimization !, especially the fDCTQuant method :) In my tests, it’s about 5-10% faster which is already pretty nice !
    I have updated the online version with your additions.


    Saturday, May 30, 2009 at 10:48 am #
  100. MBP 2.6GHZ CORE 2 DUO
    4GB ram

    original : 13161ms
    optimized : 2810ms

    cooool !!!

    Saturday, May 30, 2009 at 8:29 pm #
  101. Kyle Lu wrote:

    Well, who need the Vector?

    Sunday, May 31, 2009 at 7:30 pm #
  102. Thibault Imbert wrote:

    Hi Kyle,

    Awesome optimization with linked lists !. It allows you to have same performance improvements also in FP9 (as I read before you are stuck to FP9 for your developments right now, you must be freakin’ happy) great job :)


    Sunday, May 31, 2009 at 7:46 pm #
  103. Kyle Lu wrote:

    Yeah~! Freakin’ happy! :D
    Although still about 5% slower than the Vector version, it works greatly on fp9. I love linked list!
    Thanks to this great post!

    Monday, June 1, 2009 at 4:39 am #
  104. bakedbeing wrote:

    Quad Core (2 x 2 GHz Dual-Core Intel Xeon) Mac

    4.5x improvement! What do I win??

    Wednesday, June 3, 2009 at 3:23 am #
  105. Julien Félix wrote:

    with a MacPro 2×3 GHz Dual-Core

    old 15531 ms
    new 3473 ms

    could it be possible for the png-encoder ?
    Thanks for all


    Thursday, June 4, 2009 at 11:18 am #
  106. Pure wrote:

    12458 ms VS 2842 ms…
    C’est ce qu’on appelle de l’optimisation. félicitation.

    Thursday, June 4, 2009 at 12:24 pm #
  107. oncebet wrote:

    old 31531 ms
    new 5473 ms

    Friday, June 5, 2009 at 5:35 am #
  108. Mike wrote:

    original: 13354 ms
    optimized: 2901 ms
    4.6x faster!
    …on a Dell XPS 1530 Core 2 Duo 2.5 GHz 4GB RAM


    Friday, June 5, 2009 at 11:08 am #
  109. bobr wrote:

    it’s great, thank you
    hope you would like to implement anti-freezing solution

    Sunday, June 7, 2009 at 6:06 pm #
  110. malczak wrote:

    Hi, I have updated my post about libjpeg and Alchemy.

    here are my results for 1024×1024 bitmapData. bitmapData was created using Perlin noise.
    orginal JPGEncoder : 8316ms
    Kyle’s encoder : 8982ms encoder : 5699ms
    Alchemy async encoder : 1772ms
    Alchemy sync encoder : 347ms

    Source code for alchemy project and example are available.

    Sunday, June 7, 2009 at 11:47 pm #
  111. DROP wrote:

    XP, P4 Dual 3.00GHz 2Go Ram

    original : 30289
    optimized : 7239

    Very fast !!!

    Tuesday, June 9, 2009 at 12:54 pm #
  112. Thibault Imbert wrote:


    Do you allow me to use your JPEGEncoder implementation for FP9 ? I would be happy integrating it in AlivePDF which is still targeting FP9 where I cannot use Vector.

    let me know ;)


    Wednesday, June 10, 2009 at 5:11 pm #
  113. tst wrote:


    In your code, in the method initQuantTables() – there is no reference to aasf array, which used to be in the original code. I think because of this your code is producing much bigger JPG files than it should.

    Thursday, June 11, 2009 at 2:52 pm #
  114. Lushen wrote:

    19.3 vs 4.8 I’m downloading this one right now =)

    Monday, June 15, 2009 at 5:23 am #
  115. berkovic wrote:

    XP, P4 DualCore 3.0 ghz 3 gb ram
    original : 31329
    optimized : 7256

    Wednesday, June 17, 2009 at 10:01 am #
  116. Christian wrote:

    Wow, very nice Thibault!
    I’m on a 2.4 GHz Intel Core 2 Duo.
    Original version: 19270ms
    Optimized version 4377ms

    That’s excellent!

    Friday, June 19, 2009 at 5:58 pm #
  117. Andrea wrote:

    I’m not near as tech savvy as anyone who has commented so far. I’d like to know how to install it. I have to replace it with something don’t I. Sorry if I sound like an idiot. Any help would be appreciated. Thanks so much, Andrea

    Saturday, June 20, 2009 at 10:04 am #
  118. AlexG wrote:

    So, the Alchemy C encoder is faster than encoder from this page
    Thank you all, guys!

    Saturday, June 20, 2009 at 1:24 pm #
  119. Thibault Imbert wrote:

    Hi AlexG,

    Yes if you need the fastest way to encode it, Alchemy all the way ;)


    Tuesday, June 23, 2009 at 6:54 pm #
  120. Kyle Lu wrote:

    Sorry, I’ve been busy for a while.
    The source code is open, feel free to use.
    Yes, aasf was for float encoding, which I replaced with a int encoding method.
    File size must be the side effect, or trade off for efficiency ;(

    Tuesday, July 7, 2009 at 6:52 am #
  121. Thibault Imbert wrote:

    Cool Kyle ;) Thanks.

    Tuesday, July 7, 2009 at 9:12 am #
  122. Andrew wrote:

    Core Q8400, 4G RAM, Vista x64, FPlayer

    original 15649
    optimized 3824


    Sunday, July 12, 2009 at 1:38 pm #
  123. amn wrote:

    corelib: ~43s
    optimized: ~8s

    Ubuntu 32-bit 9.04 on Thinkpad T43 (Centrino, Pentium M 2.0Ghz)

    Tuesday, July 14, 2009 at 1:10 pm #
  124. AlexG wrote:

    I had issues with Alchemy, it is compiled into an SWC and I didnt realise to use it with Flash CS3. Did someone use it?

    Saturday, July 18, 2009 at 1:00 am #
  125. Wilfrid wrote:


    Je possède un processeur Intel i7 920 boosté à 3.6 Ghz, avec lequel j’obtiens :

    Original : 10127 ms
    optimized : 2226 ms

    J’avais tendance à ne plus percevoir ses performances, mais là je suis franchement bluffé !

    Saturday, July 18, 2009 at 5:13 pm #
  126. james wrote:

    Is there any async version for this class?

    Thursday, July 30, 2009 at 6:26 pm #
  127. Thibault Imbert wrote:

    Hi james,

    Yep :


    Thursday, July 30, 2009 at 6:37 pm #
  128. james wrote:

    Hi Thibault, thanks!

    But i was looking for the pure actionscript encoder shown on this page, as i’m targeting different operating systems..

    thanks by the way

    Thursday, July 30, 2009 at 7:33 pm #
  129. Bobby Moranville wrote:

    2x 2.8 quad-core
    10Gb ram
    corelib version:12443 ms
    optomized version:2564ms

    thanks for this awesome class

    Saturday, August 1, 2009 at 10:14 pm #
  130. AlexG wrote:

    How do you install the Alchemy encoder? And how to use it?

    Sunday, August 2, 2009 at 5:48 am #
  131. Igor wrote:


    Does your SVN looks out of services. Can you provide a link to your sample and source code?

    Friday, August 7, 2009 at 4:41 am #
  132. nidin wrote:

    original : 29297ms
    optimized : 6911ms
    #Machine config#
    processor : pentium 4 multi pro
    RAM : 3GB

    Need to know more fast performance tricks in 3D manipulation with AS3 in using pv3D

    Friday, August 7, 2009 at 7:17 pm #
  133. slafko wrote:

    nice,posting results:

    original : 11271 ms
    optimized : 2977 ms

    notebook Sony VAIO FW31ZJ
    runing on 2 monitors x 1920×1080
    Flash CS4 and Photoshop CS4 running in background, Vista x64…

    Wednesday, August 19, 2009 at 12:03 pm #
  134. Jin Saburi wrote:

    Mac Pro w/9GB RAM
    2 x 3 GHz Quad-core (8 core)


    4.8x faster !!

    Thursday, August 20, 2009 at 2:46 pm #
  135. Sevas wrote:


    Saturday, October 3, 2009 at 9:10 am #
  136. MacBook Air 1.8GHz w/SSD

    Original: 27118ms
    Optimised: 4187ms

    Roughly 6.5x improvement! INCREDIBLE!

    Tuesday, October 6, 2009 at 4:13 pm #
  137. zanemx wrote:

    Awsome!!! thanks!

    Wednesday, October 7, 2009 at 12:54 am #
  138. brombs wrote:

    You are right just about 2.x and more faster, my times were:
    original corelib: 17002ms
    optimized: 3642ms

    Thursday, February 4, 2010 at 11:14 am #
  139. judah wrote:

    hi thibault, can u write a post that shows us examples of what u did that sped things up?

    Monday, February 15, 2010 at 10:19 am #
  140. baptiste wrote:

    chez moi :
    7207 ms
    2465 ms
    ma machine :
    vista intégrale sp2 64 bits
    processeur i7 940 à 2.93 GHZ
    12 go de ram
    voilà ! la biz

    Wednesday, February 17, 2010 at 11:19 am #
  141. Carl Looper wrote:

    Excellent work. There is some possible room for improvement. Vectors have a forEach() method that is at least 120 percent faster than using a for loop. You could use BitmapData.getVector() to copy the bitmapdata macroblocks into a Vector and then the RGB to YUV could be done using forEach(). Greater improvement can be acheived by putting an entire image into a Vector (rather than on a per macroblock basis) – but would require more refactoring.


    Tuesday, February 23, 2010 at 12:39 am #
  142. Jordan W wrote:

    I got an avg 15% increase in performance just by pulling out the microblock loops in encode and placing them in their own function. I’m really confused as to why that’d be faster, but I’m not going to argue with 15% performance gain ;)

    Friday, March 5, 2010 at 10:12 am #
  143. Jordan W wrote:

    As a follow up on the my post above, more gains if you:

    - move DU[ZigZag[]] to fDCTQuant() instead of having it return something.

    -small gains by shifting in RGB2YUV instead of masking. In the RGB2YUV, it’s better to use a i<64 instead of two i<8 loops. As well, moving RGB2YUV to the microblock loop instead of having it's own function is a nice boost.

    -And if you're willing to sacrifice the space, pulling the entire image into a Vector (along with using the i<64 loop instead of the two i<8 loops) at the beginning instead of 64 pixels in a set or getPixel every loop iteration provides another ~10% boost.

    All told, the file you have for download here is ~30% slower than what it can be. And OMG those int casts are ridiculous! I mean, such a huge difference for so small a thing…

    Saturday, March 6, 2010 at 11:55 am #
  144. P48l0 wrote:


    x 2.27

    Monday, March 8, 2010 at 3:10 pm #
  145. Thibault Imbert wrote:

    Hi Jordan,

    Thanks for the tips, nice optimization gain also possible here. I will try to add those asap ! :)



    Thursday, March 11, 2010 at 10:36 pm #
  146. Well done

    Original 20826 ms
    Optimized 7700 ms

    Great job

    Friday, March 12, 2010 at 1:54 am #
  147. David wrote:

    32949ms vs. 5945ms – very nice!

    Friday, March 19, 2010 at 1:05 am #
  148. 18,73s

    3 times faster. Impressive (and very efficient).

    Wednesday, March 24, 2010 at 11:31 am #
  149. I have just put up a tutorial/guide on how to use the Alchemy JPEG encoder in Flash. It’s also an example on how to use a progressbar to monitor the encoding. Check out

    Wednesday, April 14, 2010 at 2:16 am #
  150. Thibault Imbert wrote:

    Hi Klas,

    Thanks for the link !



    Wednesday, April 14, 2010 at 11:41 am #
  151. santa wrote:

    How can i use this as in flash?
    Can you please give me an fla file?
    thanks a lot!

    Wednesday, April 14, 2010 at 10:07 pm #
  152. Otto wrote:

    Hi, many thanks for this. It’s very useful.

    Jordan W, can you please post your tweaked version somewhere?

    Monday, May 3, 2010 at 9:33 pm #
  153. Igor wrote:

    original: 9455ms

    optimized version: 2797ms

    nice work.

    Thursday, June 3, 2010 at 8:41 pm #
  154. BlooDHounD wrote:

    Thursday, June 24, 2010 at 11:30 pm #
  155. Jordan W wrote:

    Ok, so in practice with the changes posted on earlier, I’m getting around 30% max increased performance even without extracting the BitmapData to a Vector. BUT, performance gain depends greatly on what version of the player, on what platform, and on what operating system – 10% being the minimum gain I’ve found. The I’ve straightened up the code a bit, and posted it here –

    A few notes, there is an “async” encode: encodeAsync(img:BitmapData, cback:Function=null, intensity:int=1) where intensity is how “async” you want it, where 1 is the fastest, taking about 15% over encode, and goes up however much you like, but 20 probably being the highest reasonable amount, adding 60% time over encode.

    A benchmark test at (1.55MB) corelib version takes a while

    Thursday, July 15, 2010 at 8:59 am #
  156. Orig: 10211
    Opt: 2029

    5.05 X faster !!!!! Amazing

    Thursday, July 22, 2010 at 5:19 pm #
  157. Dan wrote:

    6645/1868ms ~3.55
    core i7 920, 2.8Ghz, 6.4qpi
    3GB ddr3 1.3¯Ghz
    windows 7
    flash v10.1.82.76

    Thursday, August 12, 2010 at 11:15 pm #
  158. Creeo wrote:

    Core 2 Duo 2.66, 4GB RAM, HIS 3870 VIdeo, Win7, Crome: 8192ms vs 2258ms
    Great Job man!

    Thursday, August 19, 2010 at 10:35 pm #
  159. pcfan wrote:

    on I5 quad core / 4GB DDRAM3

    nice work !

    Wednesday, September 8, 2010 at 3:02 pm #
  160. BlooDHounD wrote:

    Wednesday, September 22, 2010 at 10:19 pm #
  161. Rodney wrote:

    original : 15199 ms
    optimized : 3496 ms

    Sunday, September 26, 2010 at 10:01 am #
  162. smark wrote:

    core2duo @ 2.87GHz / 4GB RAM / flash 10,1,103,19
    8848ms/2440ms = 3.63 times faster

    Saturday, November 13, 2010 at 12:31 pm #
  163. Borisjoukov wrote:

    On my Windows pc intel centrino pro 2.2GHZ processor: older version = 11153 ms and newer version = 3205.

    Thanks for this script, its very useful !

    Wednesday, December 15, 2010 at 8:22 pm #
  164. I ran into a little problem that I haven’t been able to crack yet:

    I try to convert bitmapdata that is larger than 2880×2880 (something FP10 can finally do without hacks). The image is rougly 4000×3000 pixels. Weirdly enough, it seems that this optimized JPEGEncoder is not faster than Flash’s original.

    Is it possible that the vector-based encoder is not optimized properly for such large images, or could there be another cause to this problem?

    Any suggestion is welcome!

    Tuesday, December 21, 2010 at 1:52 pm #
  165. flash wrote:

    This is a perfect Application..
    Thank you for information.

    Tuesday, January 18, 2011 at 4:53 pm #
  166. Alex wrote:

    Original: 11477ms
    Optimized: 2971ms
    3.86x faster!! Cool!! Great job!

    MacBook Pro
    2.4 GHz Intel Core 2 Duo
    4Gb DDR3

    Wednesday, January 26, 2011 at 1:20 am #
  167. casey wrote:

    Stumbled across this page, here’s my results… Win 7 64-Bit i7-740QM 1.73 GHz

    Firefox 32 bit
    11042ms vs 3319ms

    IE 64 bit (with “Square” player)
    5971ms vs 1793ms

    Pretty rad.

    Saturday, February 12, 2011 at 7:36 pm #
  168. Kevin wrote:

    Is there a way to preserve the EXIF metadata when encoding the binary.



    Wednesday, February 16, 2011 at 4:29 pm #
  169. roberkules wrote:

    5608ms vs. 1745ms

    mbp’10: core i7@2.66ghz, 8gb ram, win7, chrome, flash

    Wednesday, March 2, 2011 at 7:19 pm #
  170. emphatik wrote:

    12172 vs 2857 (AMD phenom quad black @ 2.3G)

    4.26x increase. I’d buy a bitwise programming book from you if it were available.

    Tuesday, March 15, 2011 at 7:03 am #
  171. Thibault Imbert wrote:

    Hi emphatik,

    You do not have to, it is free ;)


    Tuesday, March 15, 2011 at 7:10 am #
  172. james wrote:

    Firstly, thanks a lot for sharing this. I realise this is quite an old post, but i’m hoping you might be able to help me with something.

    I’m running a Mac book pro, 2.33 core 2 duo with 2GB ram. When i run the test on your site i get an average of,

    corelib – 19000 ms
    optimised – 4800 ms

    But when i downloaded your class and your image and tested it within my own code, even though i’m resizing the image to 1000 x 1000 pixels (using a Matrix), it takes around the same time to encode as when it’s 2880 x 2880? Infact, a lot of the time it even takes longer.

    So i then tested the corelib version within my code and it’s only 1 – 2 seconds slower, which is not the increase i was expecting.

    I then decided to test both the corelib and your own version without resizing the image and got rather disturbing results. On average it’s taking 35 seconds with your optimised version and up to around 55 seconds using the corelib version.

    My code is fairly simple, it just uses a FileReference Object to allow the user to select an image off their machine. I then use Loader.loadbytes to convert the loaded bytes to a bitmapData and then resize it down to 1000 x 1000 pixels using a matrix before i encode.

    Any idea what i might be doing to cause it to take so long?



    Saturday, April 16, 2011 at 5:27 pm #
  173. Matth wrote:


    Pour ceux que ça intéressent, j’ai effectuer une traduction en français de cet article avec un exemple :

    A bientôt,

    Thursday, June 30, 2011 at 5:53 pm #
  174. Adele has announced plans to write, record and then produce her 3 rd studio album all just by herself. She has at present written seven tracks with regard to the record and is looking for the new material to be considerably more stripped-back.

    Friday, July 15, 2011 at 9:43 pm #
  175. Pip wrote:

    Absolutely brilliant! Have used this on a Flex BlackBerry PlayBook application – original JPEGEncoder took 30 seconds to encode a 2048×1200 image at quality 100 – using your version this came down to 7 seconds – fantastic. Thank you so much for sharing this.

    Wednesday, August 17, 2011 at 4:25 pm #
  176. David Q Hogan wrote:

    Gained about 5% by grabbing the pixels once as a vector rather than repeatedly calling getPixel32()

    Monday, September 12, 2011 at 2:53 am #
  177. Kent Nguyen wrote:

    Orig: 12763
    Opt: 4246

    Wednesday, November 2, 2011 at 6:25 pm #
  178. Sly1024 wrote:

    Awesom work!
    Core 2 Duo 2.4GHz:
    Chrome Flash Player 10

    orig: 6865
    optimized: 2414

    Friday, November 11, 2011 at 10:50 pm #
  179. wrote:

    I have 2Ghz Mac, 4gb ddr2 667Mhz,
    7573ms vs 2709ms. Safari 5.1, Flashplayer 11.1.102

    Thursday, November 24, 2011 at 11:00 pm #
  180. ahmet kucuk wrote:

    9099 to 3111
    I guess this swf uses GPU, i have nvidia 335m GT and my processor is just 1.3mhz but results re fastest one so it should be related to GPU.
    (everyone published cpu)

    Monday, February 20, 2012 at 8:26 am #
  181. Liviu wrote:

    corelib: 6677 ms
    faster: 1281 ms
    the only attempt

    over 5x times faster

    Tuesday, May 22, 2012 at 11:55 am #
  182. AnryLinkage wrote:

    Original 3402
    Optimized 676
    Core i7 950, 12G Ram.

    Saturday, July 28, 2012 at 12:58 am #
  183. menfin wrote:

    Nice work Thibault, but FileReference().save causes systematic crash in IE9 with flash player 11, so you can’t save JPEG. Is this problem known ? (win 7 64 bits)

    Friday, August 10, 2012 at 11:33 am #
  184. saif wrote:

    This one is 4 times faster for sure, but I found another one which is like 7-8 times faster for this image. Didn’t test it for any other image, you can test and upgrade yours one I guess, Good luck.

    use the normal one, Async JPGEncoder shows progress but a little slower I guess, but the best thing is flash never get hang for that stupid 15 second limitation.

    Tuesday, August 21, 2012 at 3:03 am #
  185. pa1bmsce wrote:


    Saturday, September 8, 2012 at 6:13 pm #
  186. Great stuff! I translated it to C# so I can use it in Silverlight. I noticed an issue with incomplete macroblocks (width or height not dividable by 8).
    I fixed it by repeating the last pixel until the block is filled. Now the borders look fine :)

    Thursday, September 13, 2012 at 4:36 pm #

Trackbacks/Pingbacks (26)

  1. arnotify on Friday, May 22, 2009 at 9:47 am

    [...] Imbert writes at about Faster JPEG Encoding in Flash Player 10: So what did I do [...]

  2. [...] ByteArray (Thibault Imbert) has demonstrated that for the JPEG encoding in corelib it is up to 2.5 times faster using Vectors than Arrays.  Your mileage may vary heavily but it is almost a guaranteed speed boost due to less work.  This obviously has great possibilities for speeding up code that uses lots of arrays.   [...]

  3. [...] original post – Filed under ActionScript 3.0 Leave a [...]

  4. [...] 2: Thibault Imbert figured out a way to speed up JPEG encoding using the new FP10 Vector class. Good [...]

  5. [...] 业界大牛 Thibault Imbert ( 近日将很常用的JPEGEncoder类用vector类改写了一下,做了一个vector版本的JPG编码类,效率大幅提升。正好,前不久我也已经做了一个vector版本的JPEG编码类,在项目中使用,最近正在整理代码准备分享出来。当然啦,我所做的没有Thibault那么深入,仅仅是把Array换成Vector,所以现在就拿他的版本重新修改了一下,加上了异步功能。 [...]

  6. Muki Muki » Camshift: Source and explanation on Thursday, June 18, 2009 at 10:40 am

    [...] maybe vector instead of array. I talked a bit with Thibault about it. He did a nice benchmark on this [...]

  7. WS-Blog » Speed up JPEG encoding using Alchemy on Sunday, June 21, 2009 at 5:26 pm

    [...] weeks ago Thibault Imbert published an optimized version of Adobes JPGEncoder. And it rocks! However, if you may have very big-size bitmaps it takes too [...]

  8. [...] Faster JPEG Encoding with Flash Player 10 の JPEGEncoder は corelib のコードを Flash Player 10 向けに最適化されたものです。 何度かのアップデートを重ね、今ではオリジナルの4倍のスピードでエンコードできるそうです。 [...]

  9. Faster JPEG Encoding in Flash Player 10 on Monday, October 12, 2009 at 2:38 pm

    [...] [...]

  10. | ActionScript3でJPEG on Sunday, October 18, 2009 at 4:34 am

    [...] エンコード(BitmapData→JPEG)は、「as3corelib」のJPGEncoderクラスでもいいですが、FLASH Player 10 以上であれば、Vector型配列に最適化されている「Optimized JPEG Encoder」の方が処理速度が速いのでお勧め。デコード(JPEG→BitmapData)は、ちょっと面倒ですがLoaderクラスを使います。 [...]

  11. AIR Application speed tuning on Sunday, November 8, 2009 at 5:00 pm

    [...] das muß ja rennen wie nichts gutes… Laut den Benchmarks soll es wesentlich schneller sein [Link1] [...]

  12. [...] noticed how the encoding process was slow, after some searches I’ve discovered this handy optimized class from ByteArray to encode to JPEG format four times faster. Since the two classes have the same [...]

  13. A JavaScript JPEG Encoder [bytestrøm] on Friday, November 13, 2009 at 3:41 pm

    [...] me several days. I found optimized encoder versions for flash and haxe floating around the net (Faster JPEG Encoding with Flash Player 10) and tried the optimizations used there in my javascript version. As you can seen in the benchmarks [...]

  14. A JPEG Encoder for JavaScript [bytestrøm] on Friday, November 20, 2009 at 7:43 pm

    [...] me several days. I found optimized encoder versions for flash and haxe floating around the net (Faster JPEG Encoding with Flash Player 10) and tried the optimizations used there in my javascript version. As you can seen in the benchmarks [...]

  15. 异步+Vector版本的JPEG编码器 | Better Skill Better Life on Wednesday, December 23, 2009 at 9:20 am

    [...] 业界大牛 Thibault Imbert ( 近日将很常用的JPEGEncoder类用vector类改写了一下,做了一个vector版本的JPG编码类,效率大幅提升。正好,前不久我也已经做了一个vector版本的JPEG编码类,在项目中使用,最近正在整理代码准备分享出来。当然啦,我所做的没有Thibault那么深入,仅仅是把Array换成Vector,所以现在就拿他的版本重新修改了一下,加上了异步功能。 [...]

  16. JPEGlitch | MadeByPi® Blog on Thursday, January 14, 2010 at 6:32 pm

    [...] with glitched JPEG encoding in Flash and have created a version of Thibault Imbert's optimised JPEG encoder that gives control over various glitch [...]

  17. » Blog Archive » Alchemy JPG encoder on Thursday, January 28, 2010 at 2:28 pm

    [...] Alchemy – asynchronous jpeg encoding を見た時、 の JPEGEncoder と比較して 10 倍位パフォーマンス良いように見えた の [...]

  18. AIR Application speed tuning | The Way Of Flex / AIR / Flash on Saturday, March 13, 2010 at 3:51 am

    [...] ja rennen wie nichts gutes… Laut den Benchmarks soll es wesentlich schneller sein [Link1] [Link2]…Habe es dann mal implementiert und siehe da es IST wesentlich schneller… Da ich [...]

  19. Flash相册程序的内存占用优化 « UXtracer's Blog on Wednesday, March 17, 2010 at 11:00 am

    [...] 优化思考3:既然直接保存BitmapData对象很吃内存,那么我通过JPGEncoder将其转化为ByteArray再进行保存,势必会减少开销。需要使用图片时,再通过loader.loadBytes来加载ByteArray数据。 经过试验发现,经过JPGEncoder转化后的ByteArray数据很小,只占用几十KB内存,效果明显。使用loader.loadBytes加载ByteArray显示也很顺利很流程。但一个致命的问题出现了,JPGEncoder执行效率非常低下,即使只是宽高1280*800的BitmapData,转化过程也会长达6秒之久(我的机器配置不低),更糟糕的是,由于Flash是单线程运行环境,所以此操作会导致整个界面卡住,程序陷入假死状态(延伸阅读:使用Vector优化JPGEncoder执行效率 异步JPGEncoder)。 [...]

  20. [...] 2: Thibault Imbert figured out a way to speed up JPEG encoding using the new FP10 Vector class. Good [...]

  21. onebyoneblog » Glitchy Video on Sunday, October 17, 2010 at 12:23 pm

    [...] were just shameful. I wound up getting maybe .5 frames per second or so. Disgusting. I then tried Thibault Imbert’s optimized JPEGEncoder. The results were noticeably better, but still not worth sharing. I was about to give up and chalk [...]

  22. [...] There's an optimized version of the JPEG encoder for FP10 at, recommended to apply the modifications to it if you are working with Flex 4.0 and above. Tagged [...]

  23. [...] La classe jpeg encoder sur [...]

  24. [...] in must be encoded as a JPG – you can use any of the available encoders such as CoreLib, Faster JPG Encoder, or the Alchemy [...]

  25. iPad3 CameraUI Performance Problem - Flashforum on Saturday, September 22, 2012 at 12:48 am

    [...] [...]

  26. JPEG encoding fast | A Fabi World on Wednesday, December 19, 2012 at 4:04 am

    [...] go it is really good ! This entry was posted in FLEX. Bookmark the permalink. ← GWT and [...]