That's really good to know. Thanks.

I would have raised this as bug report but it was never clear whether the 'bug' was just my misinterpretation of the docs--plenty of other people assumed that 'binary data' meant base64 encoded binary data--, a deliberate omission, or a limitation of the underlying Tk libraries.

If you have any influence with those that will implement this?

What would be *really nice*, would be the possibility to (alternatively) pass the address of a buffer from which Tk would update the underlying windows bits when instructed.

In an ideal world, it would be possible to use a graphics (painting) tool, (like GD) to create and/or modify images and a presentation tool (like Tk) to display them; with having to go through multiple copy operations and format conversions to pass data between them.

Presumably, all Tk::Photo does with the data passed is convert it into the format required by the underlying OS window primitives (eg. Bitmap for windows), and then pass the converted data on to the OS for display. Tk::Photo makes use of several packages (Tk::Png, Tk::Jpeg etc.) to do the conversion.

GD uses an internal format of it's own making (the GD(1) format). I'm wondering about the possibility of adding a Tk::GD package to the suite?

If (a to be written) Tk::GD package could accept an address, and the authors of GD/bgd could be pursuaded to expose the address of their internal buffers, then once the connection was made, you could use GD to modify the image and simple force an update to the Tk::Photo widget to have it read the bits directly out of the GD buffer. That would save several copy and convert steps along the way.

The current situation of either:

• 1. Draw with GD (in it's gd format).
  2. Export (copy and convert) the data into (say) Png format.
  3. Convert that to base64.
  4. Pass that to the Tk::Photo widget, which converts it back from base64 to Png.
  5. Passes that to Tk::Png, which converts it to whatever format the underlying windowing system requries.(eg. BITMAP on windows).
  6. Then throws those bits into the device context in the OS windowing system

• Using a Tk::Canvas object with all it's hit testing, scaling and other potential, which is great if you need those facilities, but horribly slow for your basic pixel painting applications (eg. Tk Mandelbrot Fractal).

makes using Tk for graphical applications (rather than window/dialog building purposes for which it is really quite nice), a PITA.