On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
You need to cycle through cords of a visible canvas b/c even though a canvas is open they may not be placed in a visible part of that canvas.
The bug is happening because a given pd canvas doesn't have a corresponding tk canvas. This happens when the canvas is said to be «closed». When a window is minimised, it's just useless to send the «raise» command, but it doesn't cause an error message. In the case of GOP, the canvas' contents is visible, but the associated tk canvas does not an id matching the pointer of the pd canvas.
Of course lingering question is what is in the end faster in tcl/tk land: cycling through objects and refreshing them (which would be the cleaner thing to do)
Why would it be the cleaner thing to do? It's not like simpler, smaller commands are full of doorknob viruses. Tk has the commands on groups of items so that it acts on groups of items, I don't know why we're supposed to avoid that feature and call it cleaner.
or simply refreshing entire canvas and trusting that tcl/tk is implemented so efficiently that its execution offsets time required for redundant redraws.
What about trusting that tcl/tk is implemented so efficiently that when you are picking each element in the manner that they are sorted already, and raising each of them separately to the top (thus changing the order of N cords N times in a row), tcl/tk would figure out that it has nothing to redraw?... I wouldn't even be sure that *any* toolkit would figure out that situation. Whereas for raise all_cords, tcl/tk guarantees it preserves the relative order of members of all_cords, so it is possible and likely that it will figure out that nothing has changed (but not certain).
tcl/tk is notoriously inefficient but it's also very easy to make wrong guesses as to what will be done redundantly and what won't. If you are interested in accelerating your code Tk-wise, I could show you what I found about Tk's redrawing when I tried to modify tk/generic/tkCanvas.c.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Why would it be the cleaner thing to do? It's not like simpler, smaller commands are full of doorknob viruses. Tk has the commands on groups of items so that it acts on groups of items, I don't know why we're supposed to avoid that feature and call it cleaner.
Because of the same reason why I filed and corrected the redrawing bug in pd.tk that has been there for eons and which kept showing scrollbars when there should've been none (namely because when calculating bbox size the Tcl/Tk built-in call took into account all elements, including text which canvas is unable to apparently calculate properly).
For more info on this problem see: http://wiki.tcl.tk/4844
To quote pertinent part: #-------------------------------------------------------- # Get the size of all the items on the canvas. # # This is *really easy* using # $canvas bbox all # but it is also wrong. Non-scalable canvas # items like text and windows now have a different # relative size when compared to all the lines and # rectangles that were uniformly scaled with the # [$canvas scale] command. # # It would be better to tag all scalable items, # and make a single call to [bbox]. # Instead, we iterate through all canvas items and # their coordinates to compute our own bbox. #-------------------------------------------------------- set x0 1.0e30; set x1 -1.0e30 ; set y0 1.0e30; set y1 -1.0e30 ; foreach item [$canvas find all] { switch -exact [$canvas type $item] { "arc" - "line" - "oval" - "polygon" - "rectangle" { set coords [$canvas coords $item] foreach {x y} $coords { if { $x < $x0 } {set x0 $x} if { $x > $x1 } {set x1 $x} if { $y < $y0 } {set y0 $y} if { $y > $y0 } {set y1 $y} } } } }
Alternatively, search my previous post on pd-dev list regarding improved scrolling algorithm (it's included as part of that patch).
This has resulted in no observable change in performance here on my end. OTOH I now can put a number2 object with a large font (e.g. for GUI notification) in any corner of the window without scrollbars appearing for no apparent reason and potentially wreaking havoc in visual organization of content.
or simply refreshing entire canvas and trusting that tcl/tk is implemented so efficiently that its execution offsets time required for redundant redraws.
What about trusting that tcl/tk is implemented so efficiently that when you are picking each element in the manner that they are sorted already, and raising each of them separately to the top (thus changing the order of N cords N times in a row), tcl/tk would figure out that it has nothing to redraw?... I wouldn't even be sure that *any* toolkit would figure out that situation. Whereas for raise all_cords, tcl/tk guarantees it preserves the relative order of members of all_cords, so it is possible and likely that it will figure out that nothing has changed (but not certain).
This is IMHO the first valid argument against my suggested implementation you made so far and one I would agree with.
Either way, all this still leaves us with a bandaid solution that needs to be corrected (namely checking that canvas indeed exists before calling raise all_cords).
It seems to me then that encapsulating raise all_cords call into a function and prepending it with your suggested check ought to solve most if not all of the problems associated with this bug.
Ico
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
This is IMHO the first valid argument against my suggested implementation you made so far and one I would agree with.
This is because much of the rest was about peripheral issues such as what you think of pd itself, what can be done about pd itself, and about the wording you used against the current "raise all_cords". If that's late for you, it's because your thread seemed to be about so much more than the bug in question. If you spend much of your mails talking about other issues, then this is what you can expect to get.
It seems to me then that encapsulating raise all_cords call into a function and prepending it with your suggested check ought to solve most if not all of the problems associated with this bug.
I didn't think about making it a function, but it wouldn't be a bad idea, given that it's currently done in two different places.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
This is IMHO the first valid argument against my suggested implementation you made so far and one I would agree with.
This is because much of the rest was about peripheral issues such as what you think of pd itself, what can be done about pd itself, and about the wording you used against the current "raise all_cords". If that's late for you, it's because your thread seemed to be about so much more than the bug in question. If you spend much of your mails talking about other issues, then this is what you can expect to get.
<snip>
Ok, I thought that you were talking about the code structure, and not the identifiers. So I was looking at your dot pattern and trying to guess how that could work.
Another view of this correspondence would be that I was simply trying to clarify statements and bug-reports I made and which were challenged by your questions (and some would even argue insults). Of course, the fact you misunderstood what I said in response to one of your challenges certainly did not help either :-)
I think as a contributor to a number of open source projects ranging from Linux kernel to ALSA to self-standing applications to an array of collaborative endeavors that fall outside CS domain, one of the greatest obstacles to a project's growth I found to be overly protective nature towards one's contributions or what some would portray as inability to separate one's ego from the interests of the project as a whole, as then any discussion pertaining to it can quickly flare up into a territorial crapshoot where people talk but do not necessarily listen.
The very fact that we have agreed that the aforesaid problem and allied issues identified in this thread require a patch, many of which pertain to both vanilla and extended versions to me seem like a good opportunity to improve upon the software at everyone's benefit. Likewise, improving code readability is more likely to attract additional contributors. E.g. perhaps it may be a good idea to include structure casting for all pertinent identifiers you've kindly demoed a snippet of in your last email.
I am first to admit that I am a weekend warrior when it comes to coding and as such am probably not the greatest C/C++ guru on the planet. Yet, the fact is that here I've offered straightforward reasons why the specific line was not a fix but a bandaid (something we've both agreed on) and perhaps more importantly offered solutions to some of the long-standing problems associated with the gui.
I think all this could've been done with a lot less noise, once again at everyone's benefit.
Best wishes,
Ico
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
obstacles to a project's growth I found to be overly protective nature towards one's contributions or what some would portray as inability to separate one's ego from the interests of the project as a whole, as then any discussion pertaining to it can quickly flare up into a territorial crapshoot where people talk but do not necessarily listen.
Ok, I don't have any code in vanilla nor extended, and if I had any, I wouldn't consider it an achievement. Now if only you were reading me accordingly...
Likewise, improving code readability is more likely to attract additional contributors. E.g. perhaps it may be a good idea to include structure casting for all pertinent identifiers you've kindly demoed a snippet of in your last email.
Yeah, it's all nice, but how do you get improvements like that in the branch(es) that you want to improve?
I am first to admit that I am a weekend warrior when it comes to coding and as such am probably not the greatest C/C++ guru on the planet.
You needn't say that. I still wanted to say that chances are you did a lot more with those 40 hours than just hunting bugs, so, if ever a bugfix is rejected or buggy or the issue becomes moot, you haven't really wasted 40 hours on it. It's actually part of the trick to get less territorial about the code: no matter how much of the code gets flushed and ignored, you learned a lot of things that you can use somewhere else, and those hours will always be with you.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Ivica Ico Bukvic -
Mathieu Bouchard