Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1821174 ] RenderBadPicture (invalid Picture parameter)
|
From: SourceForge.net <no...@so...> - 2012-03-02 15:43:17
|
Bugs item #1821174, was opened at 2007-10-27 04:35 Message generated for change (Comment added) made by jlec You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1821174&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 67. Unix Window Operations Group: obsolete: 8.5b3 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Joe English (jenglish) Summary: RenderBadPicture (invalid Picture parameter) Initial Comment: Playing with BWidget, I've discovered some kind of error. How to repeat: 1. Take the BWidget template from http://wiki.tcl.tk/8289 2. Before last line ("main") insert a line containing: rename send {} 3. When the demo has been run - choose "Exit". There will be an error message: #v+ X Error of failed request: RenderBadPicture (invalid Picture parameter) Major opcode of failed request: 153 (RENDER) Minor opcode of failed request: 7 (RenderFreePicture) Picture id in failed request: 0x1200080 Serial number of failed request: 996 Current serial number in output stream: 1017 #v- The problem doesn't occur in 8.4.12. Debian Etch, Tcl/Tk 8.5b1, BWidget 1.7 ---------------------------------------------------------------------- Comment By: jlec (jlec) Date: 2012-03-02 07:43 Message: Is there a fix now. I have a program which suffers from this and blocks the xft inclusion into tk. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2008-04-11 13:52 Message: Logged In: YES user_id=68433 Originator: NO > Is it understood why the following [...] Yes: in that session, no font rendering occurs. The RenderBadPicture error occurs when a Tk_Font is destroyed and (inhale) the Drawable associated with the Picture inside the XftDraw * belonging to the Tk_Font (exhale) has already been destroyed, thus invalidating the Picture. The Tk_Font caches the last Drawable it was used on, to amortize the XftDrawChange() cost across multiple consecutive calls to Tk_DrawChars() with the same font and Drawable. I suspect that the error is only generated if the Drawable is a Window, not when it's a Pixmap, since the error only appears to be replicable if there is a [menu] widget present. (Most widgets draw into a background Pixmap, [menu] widgets draw directly onto their Window). In any event, it's a problem with the shutdown order. Removing [send] does not *cause* the problem; rather, it's that the presence of [send] changes the shutdown sequence so that the problems are masked. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-04-11 09:25 Message: Logged In: YES user_id=80530 Originator: NO Is it understood why the following session in a plain interactive wish does not suffer the same problem? $ wish % rename send {} % exit $ ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2007-11-01 14:59 Message: Logged In: YES user_id=68433 Originator: NO Priority: 8; Severity: 1. This is a real bug, and ought to be fixed before 8.5.0, but it's not severe: the worst end-user consequence is a confusing/annoying error message at program shutdown in (probably-) rare circumstances. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2007-10-27 14:53 Message: Logged In: YES user_id=68433 Originator: NO Origin of the RenderBadPicture error: XftDrawDestroy() from FinishedWithFont() from TkpDeleteFont(), called when the last reference to the font is removed (... in this case: Tk_FreeConfigOptions, called from a Destroy handler from Tk_DestroyWindow). At this point the Picture ID in fontPtr->ftDraw will refer to the drawable specified in the most recent call to XftDrawChange(); which in turn could be a Window that's already been destroyed. XRENDER docs are sketchy on this point -- it's not clear if destroying a Drawable invalidates Pictures that refer to the drawable, but it's a reasonable assumption. Now the FinishedWithFont() procedure body is wrapped in a Tk_CreateErrorHandler() / Tk_DeleteErrorHandler() pair, so this error *should* be caught and trapped. More printf-tracing indicates that this is the case in the non-error condition. Stack trace for the error condition shows: ErrorProc _XError _XReply XSync TkpCloseDisplay TkCloseDisplay DeleteWindowsExitProc and single-stepping through ErrorProc (generic/tkError.c) indicates that the call to TkGetDisplay() returned NULL. The reason it returns NULL is because DeleteWindowsExitProc sets tsdPtr->displayList to NULL before calling TkCloseDisplay() on each member of the list. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2007-10-27 13:45 Message: Logged In: YES user_id=68433 Originator: NO Re: what does [rename send {}] have to do with this: When the ::send command is destroyed DeleteProc() in unix/tkUnixSend.c is called which (among other things) calls XSync(). The ::send command is normally destroyed as part of Tk's shutdown sequence; but if the application deletes it early, this won't happen at shutdown time. Exact sequence of events still unclear. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2007-10-27 11:59 Message: Logged In: YES user_id=68433 Originator: NO | Tentative hypothesis: [...] Nope, that does not appear to be the case; DisplayMenu is called at the right time. Only other difference I can think of between menus and other widgets is that most widgets render into an offscreen pixmap, while menus render directly to their Window (#791527). And what does [rename send {}] have to do with this? ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2007-10-27 10:51 Message: Logged In: YES user_id=68433 Originator: NO Symptoms do not occur under "--disable-xft". Problem seems to be limited to menus: replacing [. configure -menu $mb] with [pack [label .l -text "..."]] or some other widget, the symptom does not appear. Tracing with printf()s indicates that MeasureChars (unixRFont.c) is being called sometime between the [destroy .] and the X error. Tentative hypothesis: the menu widget is processing an <Expose> binding during or after application shutdown? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-27 09:57 Message: Logged In: NO Replicated with current CVS HEAD. Shorter script that replicates the problem: # ---- cut here ---- rename send {} set mb [menu .menubar] $mb add cascade -label "File" -menu [menu $mb.file] $mb.file add command -label Exit -command [list destroy .] . configure -menu $mb tkwait visibility . destroy . # ---- end ---- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1821174&group_id=12997 |