Fail to create pixmap when putting images on canvas (windows)
Roy Terry
other Tk developers who use
canvas images on Windows.
---------------------------------------------------------------------------------------------------------------
On Windows, Adding many images about 400+ to canvas (depending on
image
size?) causes fatal Tk error
"Fail to create pixmap with Tk_GetPixmap in ImgPhotoInstanceSetSize".
Simply allocating a like number of images (or even many more) does not
cause the error. This issue exists in all tested versions of Tcl/Tk
8.4.x,
8.5.x, 8.6b1.1
A demo script with GUI and sample image is attached.
Possibly (probably?) relevant history:
G. Howlett on Windows GID object management in same contex
(interesting!) :
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/8526d7d05
b33701d/3858f4ce5283b311?hl=en&lnk=gst&q=pixmap+fail#3858f4ce5283b311
Georgios Petasis has issues in 2004:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/9e446aaf5
862d578/dd65b1eb988c7717?hl=en&lnk=gst&q=pixmap+fail#dd65b1eb988c7717
Possibly related:
http://objectmix.com/tcl/364908-windows-memory-leak-weird.html
The Bug item:
https://sourceforge.net/tracker/index.php?func=detail&aid=2748171&group_id=12997&atid=112997
Direct link to demo script/image:
https://sourceforge.net/tracker/download.php?group_id=12997&atid=112997&file_id=322057&aid=2748171
George Peter Staplin
Hi Roy,
This is actually a known issue, without a known solution. When you create
more than a certain number of pixmaps with a sufficient size Tk fails,
often when there is plenty of RAM. There is a related bug in the tracker.
Tk_GetPixmap uses CreateBitmap(), and there are some limitations with that.
From what someone said in a bug report related to this I think they
suggested using CreateDIBSection to avoid the problem. I don't now why
that would change the behavior, but if you do, please share.
-George
twowheel
wrote:
> Roy Terry wrote:
> > I am repeating a bug item here as an FYI or matter of interest to
> > other Tk developers who use
> > canvas images on Windows.
> > ---------------------------------------------------------------------------------------------------------------
>
> > On Windows, Adding many images about 400+ to canvas (depending on
> > image
> > size?) causes fatal Tk error
> > Simply allocating a like number of images (or even many more) does not
> > cause the error. This issue exists in all tested versions of Tcl/Tk
> > 8.4.x,
> > 8.5.x, 8.6b1.1
>
> > A demo script with GUI and sample image is attached.
>
> > Possibly (probably?) relevant history:
>
> > G. Howlett on Windows GID object management in same contex
> > (interesting!) :
>
>
> > Georgios Petasis has issues in 2004:
>
>
> > Possibly related:
> >http://objectmix.com/tcl/364908-windows-memory-leak-weird.html
>
> > The Bug item:
>
>
> > Direct link to demo script/image:
>
>
> Hi Roy,
>
> This is actually a known issue, without a known solution. When you create
> more than a certain number of pixmaps with a sufficient size Tk fails,
> often when there is plenty of RAM. There is a related bug in the tracker.
> Tk_GetPixmap uses CreateBitmap(), and there are some limitations with that.
> From what someone said in a bug report related to this I think they
> suggested using CreateDIBSection to avoid the problem. I don't now why
> that would change the behavior, but if you do, please share.
>
> -George
Thanks George,
A few questions:
1. Any further info about the related bug in the tracker. I'd like to
know which you're thinking of.
2. You say no solution but go on to suggest a possible solution, using
CreateDIBSection() instead of CreateBitmap(). Could that not work?
(From chance googling I saw someone say that CreateBitmap uses the
video card memory whereas CreateDIBSection uses system memory. That
may explain the improved behavior I think.
twowheel
Jeff Hobbs
I'm not sure if it is the patch George is referring to, but there is a
similar issue at http://bugs.activestate.com/show_bug.cgi?id=80733.
Note that I haven't been able to repro, and the author actually said
they have their own issues with the patch, but if you want to test
yourself and give feedback that would be appreciated.
Jeff
George Peter Staplin
Jeff, that's the bug I was referring to. I forgot it was at the ActiveState
bug tracker, and not the SourceForge tracker.
This issue seems strange, because I don't believe they have documented which
part of the system hardware allocates the bitmap. It could be that the
information Roy found is correct though, in which case I have more
questions than answers.
I recall that with NexTk I used CreateDIBSection at one point in the
ntk.dll. There was also a need for GDIFlush() calls IIRC before some
critical regions when working with the shared memory for the bitmap.
-George
George Peter Staplin
There was also another report that I believe was mentioned years ago. I
remember something like this going unresolved. I was mixing up the 2
issues I think in my memory. I will look for more evidence.
-George
George Peter Staplin
Ugh, the CreateBitmap is using VRAM from what the comments say here, and
elsewhere from a Google search:
http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.htm
There are also other limitations mentioned there. I think a DIB might be a
better solution for Tk.
It appears that the patch could be failing due to not calling ReleaseDC()
after CreateDIBSection() uses the value of GetDC().
I think it should probably be:
HDC dc;
dc = GetDC(NULL); /* Get the screen device context... */
CreateDIBSection(dc, ...);
ReleaseDC(NULL, dc);
Then just SelectObject and BitBlt as usual.
-George
twowheel
Ok. I will attempt to build and test the improved patch in the next
3-4 days.
twowheel
I have patched tkWinPixmap.c with George's HDC fixup and had positive
results. It appears this may banish the problem but more and broader
testing is certainly needed. I have updated the bug report too. I
will continue to use this experimental build with our app and report
any negative behavior. The build was using mingw with 8.6 nightly
snapshots from the last 5 days.
BUG ITEM LINK (repeated from above)
https://sourceforge.net/tracker/index.php?func=detail&aid=2748171&group_id=12997&atid=112997
George Peter Staplin
From what Jeff Hobbs (tclguy) said yesterday, when I raised this issue at
the Tcler's Chat, he can't duplicate the problem, and he wants a test case
that fails.
I have not tried to duplicate it yet in Windows. Based on the information I
have gathered the actual limit depends on video card memory, and perhaps
video driver restrictions as well. So, perhaps we need a better test case
that shows the total pixmap memory consumed (based on the size and color),
to compare it to the available RAM of some systems. An alternative might
be to contact someone at Microsoft about this issue, and see if they have
any insight they might be able to share.
-George
twowheel
>
> From what Jeff Hobbs (tclguy) said yesterday, when I raised this issue at
> the Tcler's Chat, he can't duplicate the problem, and he wants a test case
> that fails.
>
> I have not tried to duplicate it yet in Windows. Based on the information I
> have gathered the actual limit depends on video card memory, and perhaps
> video driver restrictions as well. So, perhaps we need a better test case
> to compare it to the available RAM of some systems. An alternative might
> be to contact someone at Microsoft about this issue, and see if they have
> any insight they might be able to share.
>
> -George
Jeff Hobbs has modified the patch I used and has closed the bug report
at sourceforge - no more comments allowed.
My experience is the following
1. Am still using the patch as reported earlier and have confirmed no
bad side effects. Nor have I noticed any speed degradation.
2. Agreeing with George, it seems this bug (total crash of tk) is
system dependent. There may be no example that reproduces on Jeff's
machine. I have at least two machines that will crash every time: 1)
Lenovo T60, Windows XP pro service pack 3 with ATI Mobility Radeon
X1400 with 512MB memory and 2) A high-end HP laptop with 17 inch
screen purchased new last year. So this is not a problem for obscure
machines only
3. Jeff has modified the path to continue calling the old API:
CreateBitmap until it fails. This may be a problem as it allows Tk to
gobble up a lot of resouce that other apps may need. In my testings,
with repeated failures, eventually firefox failed to draw web pages
and I had to restart the system. My preference would be to call
CreateDIBSection in call cases. Jeff, you mention a difference in
speed. Can you give any measurements?
4. I will probably try Jeff's version at some point like the next Beta
of 8.6 and report
5. Again, I see no problems with the straight substitution and think
the wait-till-it-fails approach could just make the stability issues
more insidious.
6. It is really unclear to me that the large bitmap failure is really
full overlapped with the many canvas images failure as Jeff asserts.
Perhaps.
Thanks George and Jeff for your attention to this nasty bug.
Roy
Jeff Hobbs
> Jeff Hobbs has modified the patch I used and has closed the bug report
> at sourceforge - no more comments allowed.
Actually it was DKF who got to it first and applied a variant user-
contributed patch.
> My experience is the following
> 1. Am still using the patch as reported earlier and have confirmed no
> bad side effects. Nor have I noticed any speed degradation.
> 2. Agreeing with George, it seems this bug (total crash of tk) is
> system dependent. There may be no example that reproduces on Jeff's
...
> 3. Jeff has modified the path to continue calling the old API:
> CreateBitmap until it fails. This may be a problem as it allows Tk to
> gobble up a lot of resouce that other apps may need. In my testings,
> with repeated failures, eventually firefox failed to draw web pages
> and I had to restart the system. My preference would be to call
> CreateDIBSection in call cases. Jeff, you mention a difference in
> speed. Can you give any measurements?
Then firefox has the same bug we had. ;) I don't mind making the
direct call to CreateDIBSection alone, and can make the change with
enough prodding.
> 4. I will probably try Jeff's version at some point like the next Beta
> of 8.6 and report
I can drop you an updated AT binary for testing.
> 5. Again, I see no problems with the straight substitution and think
> the wait-till-it-fails approach could just make the stability issues
> more insidious.
> 6. It is really unclear to me that the large bitmap failure is really
> full overlapped with the many canvas images failure as Jeff asserts.
> Perhaps.
It's actually not a wait-til-it-fails, which is what I'm worried
about. It only falls back on each and every try made with
CreateBitmap. The next time through it will still try CreateBitmap
before falling back again. That's why the direct call to
CreateDIBSection may be preferred.
Jeff