The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

Changes for version 5.90

  • There have been numerous issues with 16 bit mode and color mapping. They mainly are a result of Imager not being able to work in a RGB565 color mode. All operations have had to convert from RGB565 to RGB888 and visa versa for each and every Imager operation. This causes errors and artifacts, among other things. They compound themselves the more operations done. So... here's what I did:
  • If you have a 16 bit display, you need to use double buffering. How do you do that you may say? Well, it's actually quite easy, and does not involve modifying legacy code to any great deal. You need to have TWO instances of Graphics::Framebuffer instantiated. One for the "real" actual 16 bit framebuffer, and another in virtual framebuffer mode with 32 bit (or 24) color mode (I think you see where I am going). You do ALL of your drawing, loading, etc on the virtual framebuffer object, and then "flip" it with the real framebuffer object by means of the new "blit_flip" method (examples in the documentation).
  • What this does is do a single one-way 32 (or 24) bit to 16 bit conversion then blits it to the 16 bit screen for the entire screen. This is called "double-buffering". Yes, generally things can be a little slower, but this is a fast compiled C routine, and is pretty darn fast even on a Raspberry PI2. If you only call "blit_flip" for when a complete screen is drawn and not after each draw operation, then you can speed things up more.
  • The "examples/primitives" script has been modified to exhibit this behavior for 16 bit displays. I have not modified the threading example, as it's methods really do not need double-buffering.
  • You do not have to do double-buffering. All primitives, etc operate as they did before in 16 bit mode, but if you are working with fonts and images, then I highly recommend it. Just remember, if you do use double-buffering, then do not draw to the 16 bit screen directly, as "blit_flip" copies from the virtual object, which only has screen data that has been drawn to it. So do all operations (drawing, loading, blitting, etc) on the virtual display.