RE: [MACTCL] Re: TkPutImage crash on very wide images

[Schollnick, B. <Ben...@us...>]

Now, please keep in mind, I haven't gone through the MacPython
source code, but I've seen the identical symptoms...

Here's my summary:

	Is there any reason that Tkinter (Tkinter.Tk()) Initialization
	might fail, if it already exists?

	i.e.

		Test = Tkinter.Tk()
		Test2 = Tkinter.Tk()

	What was happening was that I initialized Tk, and then
	I didn't pass the Root to the Wizard GUI package... Which
	then initialized it again...

	But, as I am apt to do, this does not cause an issue on the
	PC Python (Cpython)....

	I already posted a inquiry on the mac-tcl list,
	but will follow that up....

	But, I assume this is a Tcl core issue?  And what version of
	Tcl did Python v2.11 ship with?

Right from the source...(From the MacTCL list):

> From: Jim Ingham [mailto:ji...@ap...]
> Sent: Wednesday, November 07, 2001 2:39 PM
> To: Schollnick, Benjamin
> Cc: 'tc...@li...'
> Subject: Re: [MACTCL] RE: Problems with Mac TCL?
>
>
> Benjamin,
>
> First off, Tcl/Tk is not designed to allow you to load two independent
> copies of Tk into an application.  There is global state in the
> libraries that will cause conflicts.  So you have to make sure that you
> unload the first copy completely before you try to load the second
> copy.  You can create two tcl interpreters, both running Tk, but the way
> you are supposed to do that is to create one interpreter, and then load
> Tk into the second interpreter by running "package require Tk" in the
> second interpreter.  This is, for example, how the console window in
> MacTk works.  But we never intended you to be able to actually load the
> Tk library twice.
>
> Theoretically, you could load Tk, then unload it. However, I never
> worked very hard to make sure that you could unload Tcl/Tk from an app,
> and then reload it again cleanly.  There are finalization routines for
> all the subsystems, but I would have no problem believing they don't
> clean up everything.  The only things I really cared about was
> non-shared state, and resources that the system would not reap when the
> process exited.  You could probably fix this - since the mechanism to
> handle finalization is present.

What I suspect is happening is, since the IDE never unloads, the TK/Tcl
library's are still initialized.... The second time you run the program,
the library attempts to initialize, can't grab/generate the "Window ID#256" 
and fails.... 

(This is the assumption)  The IDE imports the library's into it's own
name space, since in Classic there no way to make a "truly" separate
process.... (In Mac OS X, probably that would spawn another process.)

Sorry if I was not clear enough, previously....

I still think this is a problem, especially since the PC (aka Cpython)
version doesn't have this problem.... But when I (briefly) examined
Tkinter.py
I didn't see anyway to work around this issue, without causing significant
code issues between the PC & Mac versions of python....

			- Benjamin

-----Original Message-----
From: Jim Ingham [mailto:ji...@ap...]
Sent: Monday, December 10, 2001 1:23 PM
To: Daniel A. Steffen
Cc: tc...@li...; sca...@la...
Subject: [MACTCL] Re: TkPutImage crash on very wide images


Daniel,

On Sunday, December 9, 2001, at 11:31  PM, Daniel A. Steffen wrote:

> Dear All,
>
> tkMacDraw.c's TkPutImage crashes in CopyBits when using very wide 
> images.
>
> I have a case here where a Tk app (which is working fine on unix & win) 
> uses an image 4846 pixels wide (and 32 bits deep), which results in a 
> bytes_per_line value of 0x4BB8. However, according to IM, PixMap's 
> maximal value for rowBytes is 0x3FFF (c.f. [1]) and indeed CopyBits 
> crashes on the PixMap constructed by TkPutImage with
> 	pixmap.rowBytes = image->bytes_per_line | 0x8000;
> (rowBytes is a short whose high 2 bits are used as QD flags, thus the 
> 0x3FFF limit)
>
> In practical terms this means that Tk will crash when using any 32bit 
> image wider than 4095 pixels.
>
> Not sure what the best solution is here, I've now added a panic before 
> the CopyBits to at least exit gracefully, a better solution would be to 
> split the image into blocks that are maximally 0x4000 bytes wide and do 
> CopyBits on each block... The question is how common is the use of 
> images this wide, is it worth putting in time to get this to work?
>

This depends on how much free time you have.  Not many screens can 
display an image this big, so I wouldn't imagine this is all that common.

> BTW, this problem almost certainly also exist on TkAqua, as TkPutImage 
> is essentially unchanged in tkMacOSXDraw.c (and Carbon CopyBits still 
> uses Bit 15 as a flag)
>

Yes, but I would solve this problem on X not by breaking the image up, 
as you would have to on 9, but by replacing CopyBits with a CoreGraphics 
problem at some point, since that would also open the possibility of 
compositing with alpha channels as well.  So I don't think this is a 
motivation to do this work on 9 (of course, who knows when I will get 
around to this...)

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer


_______________________________________________
Tcl-mac mailing list
Tc...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-mac