RE: [Tkimg-devel] Re: Img, reorg of build system

[Andreas K. <andreask@ActiveState.com>]

> > Speed improvements with ReadBuffer up to 2 times, depending on the
> > format.
> > I agree with you, that the current implementation is not very good.
> > As is written in the source, it was just a quick hack.
>
> (With the comment that I haven't looked at source code...)
>
> Is this about reading a large image file into memory?

Partially. His code is there to help when decoding compressed image files
(RLE)
which have to read byte by byte. The read buffer code reads blocks and
dispenses
them to the actual reader code. One level of caching.


> If so, are there plans to make things more memory based and then using
> memory-mapped files as one way of loading data?

Background regarding the image subsystem of Tk:

*	We can have an unbounded number of image 'type's registered in Tk.
	A type talks nearly directly to X AFAIK.

	Currently there are two:	bitmap, and photo

*	An image type can have an unbounded number of 'formats' registered.
	A 'format' handler converts external data into the internal format
	of the 'type' and back.

	The image type takes the external data and calls out to the format
	to do this.

	There are currently 2 ways of specifying the external data to the
	photo image type.

	1	Tcl_Obj.	The external data resides in a Tcl_Obj, completely
				in memory. It may be base64 encoded (older Tcl's).

			At the tcl level the option is -data

	2	Channel.	The external data is in a channel. The format handler
				will read from/write to the channel. It was opened by
				the photo image type.

			At the tcl level the option is -file

Now memory mapping. We can do any of the following

	a	Extended the VFS to allow mem-mapped opening of a file
		returning a memory block (ptr) instead of a channel. Then
		extend the photo image type to call out to its formats using
		this mem-block (Maybe wrap it into an immutable ByteArray
		Tcl_Obj and use (1) ?).

	b	Extend the channel system to be able to read files via
		memory mapping (channel driver, also needs changes in the
		generic part as buffering might not be needed. But keep
		encoding conversions in mind too !)

>
> Somewhat tangential to this: what are is the relationship between img
> and things like imagemagick or other image libraries (my ignorance
> probably shows here...)?

ImageMagick (IM) has several components. One of which is reading and writing
of data in various formats, to the internal format of IM. I am not sure if
this part can be grafted to Tk's image subsystem.

Another part of IM are image manipulation algorithms. As they operate on
IM's
internal rep. grafting them to Tk and its operations is in doubt too.

... Maybe it can be handled through a separate image type instead of format
handlers to photo.

>  The reason for asking is to understand what
> you folks think would be an appropriate for image handling longer term?

One of the long term things I would advocate would be to separate the
Tk image susbsystem form Tk, and make it an extension. something which
can be used by Tcl only. Alas, this requires TIPs for Tk and maybe even Tcl.

> If development on things such as reading data is contemplated - would
> it be an option to pick a few more giants' shoulders to stand on?



--
	Andreas Kupries <andreask@ActiveState.com>
	Developer @ http://www.ActiveState.com