Yeah and afaiu this is exactly the job that HC just started (see his announcement below). Yvan: in my simple understanding it goes like this: 1. getting rid of tcl-specific code in pd c core 2. minimizing the communication between the core and the gui (3. defining the api/protocol?) 4. anyone can go make all sorts of guis for pd... at this point or later on vanilla may or may not switch from tcl - imho it's to be decided when we're there
Andras
On Fri, Aug 26, 2011 at 01:39, Jonathan Wilkes jancsika@yahoo.com wrote:
The pd/pd-gui divide is a little misleading-- there are lots of places in the c code where there are sys_gui and sys_vgui calls with tcl in them, plus c code that probably assumes tcl is being used on the gui side.
You'll either need to write a wrapper for those calls, or modify a lot of c code and basically make a fork (iemguis, canvas stuff, etc.)
But even if you write a wrapper, there are still issues that will need to be dealt with on the c side to minimize the number of messages passing back and forth between pd and gui. For example, there is one call per xlet to the gui when an object gets instantiated/vis'd, plus drawing the border and text, rather than one call per object (and letting the gui deal with where to draw xlets, box width, font, etc.).
-Jonathan
*From:* yvan volochine yvan.pd@gmail.com
*To:* Hans-Christoph Steiner hans@at.or.at *Cc:* Jonathan Wilkes jancsika@yahoo.com; pd-dev List pd-dev@iem.at *Sent:* Thursday, August 25, 2011 6:18 PM *Subject:* Re: [PD-dev] tkwidgets
On 08/17/2011 08:54 PM, Hans-Christoph Steiner wrote:
I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui <--> pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable.
hiho
sorry for bumping in but what about giving up tcl-tk and go on with something more "modern" (à la Qt), with a decent OO interface ?
I might miss the obvious as I'm new here but what about rewriting pd GUI in Qt ? wouldn't it make more sense than spending time hacking on and on tcl-tk code ?
my 0.001$ _y
On 08/26/2011 02:19 AM, András Murányi wrote:
Yeah and afaiu this is exactly the job that HC just started (see his announcement below). Yvan: in my simple understanding it goes like this: 1. getting rid of tcl-specific code in pd c core 2. minimizing the communication between the core and the gui (3. defining the api/protocol?) 4. anyone can go make all sorts of guis for pd... at this point or later on vanilla may or may not switch from tcl - imho it's to be decided when we're there
ah ok, thanks for the clarification. doesn't look like an easy task indeed ;)
cheers, _y
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.
From: András Murányi muranyia@gmail.com To: pd-list pd-list@iem.at Sent: Thursday, August 25, 2011 8:19 PM Subject: Re: [PD] [PD-dev] tkwidgets
Yeah and afaiu this is exactly the job that HC just started (see his announcement below). Yvan: in my simple understanding it goes like this: 1. getting rid of tcl-specific code in pd c core 2. minimizing the communication between the core and the gui (3. defining the api/protocol?) 4. anyone can go make all sorts of guis for pd... at this point or later on vanilla may or may not switch from tcl - imho it's to be decided when we're there
Andras
On Fri, Aug 26, 2011 at 01:39, Jonathan Wilkes jancsika@yahoo.com wrote:
The pd/pd-gui divide is a little misleading-- there are lots of places in the c code where there are sys_gui and sys_vgui calls with tcl in them, plus c code that probably assumes tcl is being used on the gui side.
You'll either need to write a wrapper for those calls, or modify a lot of c code and basically make a fork (iemguis, canvas stuff, etc.)
But even if you write a wrapper, there are still issues that will need to be dealt with on the c side to minimize the number of messages passing back and forth between pd and gui. For example, there is one call per xlet to the gui when an object gets instantiated/vis'd, plus drawing the border and text, rather than one call per object (and letting the gui deal with where to draw xlets, box width, font,
etc.).
-Jonathan
From: yvan volochine yvan.pd@gmail.com
To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; pd-dev List pd-dev@iem.at Sent: Thursday, August 25, 2011 6:18 PM Subject: Re: [PD-dev] tkwidgets
On 08/17/2011 08:54 PM, Hans-Christoph Steiner wrote:
I've started a private git branch of tkwidgets
that I intent to push once I get somewhere with it. The idea
is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui <--> pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable.
hiho
sorry for bumping in but what about giving up tcl-tk and go on with something more "modern" (à la Qt), with a decent OO interface ?
I might miss the obvious as I'm new here but what about rewriting pd GUI in Qt ? wouldn't it make more sense than spending time hacking on and on tcl-tk code ?
my 0.001$ _y
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/26/2011 05:31 PM, Jonathan Wilkes wrote:
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
- difficult to implement a decent zoom function for a canvas
- can't display png without the Img library (included in 8.6)
- can't do alpha transparency
- you have to write ugly code ?
_y
On 2011-08-26 11:31, Jonathan Wilkes wrote:
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
- difficult to implement a decent zoom function for a canvas
- can't display png without the Img library (included in 8.6)
- can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.)
I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.
- Because tcl/tk is an interpreted language it is a lot slower than a
compiled language: you have a script in ASCII that has to go through a processor that interprets the script to call a lower-level machine that actually does the work, while Qt is compiled so it does what you ask it directly, more or less.
- tcl/tk behaves differently on the three main platforms. See the
problems with font sizing for instance.
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: András Murányi muranyia@gmail.com; pd-list pd-list@iem.at Sent: Friday, August 26, 2011 2:30 PM Subject: Re: [PD] [PD-dev] tkwidgets
On 2011-08-26 11:31, Jonathan Wilkes wrote:
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
- difficult to implement a decent zoom function for a canvas
- can't display png without the Img library (included in 8.6)
- can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.)
I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.
- Because tcl/tk is an interpreted language it is a lot slower than a compiled
language: you have a script in ASCII that has to go through a processor that interprets the script to call a lower-level machine that actually does the work, while Qt is compiled so it does what you ask it directly, more or less.
- tcl/tk behaves differently on the three main platforms. See the problems with
font sizing for instance.
You cannot guarantee the exact same font metrics across platforms, no matter what toolkit you use, because they depend on the font rendering engine of that particular platform. I checked this out in qt documentation, and the solution was the same as it should be for tcl/tk: have a loop where you measure the width of your text at font size x and increment x until it fits the box without overlapping.
Other than the font, however, the vector drawings on a tk canvas are the same across platforms.
Martin
tcl/tk behaves very slowly for fast calls, such as when dragging an array
of considerable size, or a big group of objects? afaik this is something
that could be improved in the present platform, but how better could it be
when using another gui framework?
It might be a good idea to list the problems with tcl/tk so we can weigh
them against the difficulty of using a different GUI toolkit. The
problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means
that (without prior planning) it's hard to take a patch you've been
working on at font size 10 and display it adequately over a projector,
for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
From: João Pais jmmmpais@googlemail.com To: András Murányi muranyia@gmail.com; pd-list pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Sent: Friday, August 26, 2011 5:19 PM Subject: Re: [PD] [PD-dev] tkwidgets
tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework?
We should separate poor tcl/tk performance from, well... I don't exactly know what to call this:
A "Put" menu array with default settings has:
a text item for a label
a line item in the shape of a rectangle for the border (why not a rectangle?)
a rectangle item for each element of the array that can fit visibly inside the graph (why not lines?)
Anyway, if the width of the graph in pixels is greater than the number of elements, the rectangles are elongated to fill the space in between. These are the "steps" you get when filling a 100 pixel wide graph with an array of 10 elements.
If the width of the graph in pixels is less than the number of elements, then one rectangle stands in for multiple array elements. Thus for a 10 pixel-wide graph holding a 100 element array, you get 10 elements per pixel.
So far so good.
Now, starting with a "Put" menu array with a graph only 10 pixels wide, increase the size of the array while keeping the graph width constant.
At size 10000 or even 100000 it may look like tcl/tk is getting sluggish, but if you use the tcl prompt you can confirm that tk indeed keeps a constant number of rectangle items-- in this case, 10-- on the canvas regardless of the # of elements in the array. (Granted it's deleting and re-creating instead of just moving the thing, but let's set that aside for the moment.) What's going on here?
Once you get up to about 10 million elements, you can see a symptom of the problem-- pd is sequentially sending messages for each rectangle item, and in debug mode the latency between each message arriving at the gui side is quite noticeable. Obviously there must be some calculation on the C side of things that involves every element represented by that rectangle. So if you have a 10 pixel-wide graph and 10 million elements, that would mean Pd is doing some calculation that involves 1 million elements PER ARRAY RECTANGLE. And this happens for _every_ pixel you happen to be moving the graph! You can't blame tcl/tk for this-- it's moving those rectangle items as fast as it receives them from Pd.
This is all to say: choose any toolkit you want, but unless it has a (non-buggy) time travel widget, there's no way it's going to move that 10 million-element array faster than pd can finishing playing a million games of tic-tac-toe*, or whatever it's doing between each "$canvas rectangle create etc." message that it's sending.
-Jonathan
- Maybe the solution is to make Gridflow part of Pd vanilla, so we can use it to play tic-tac-toe-between-array-rectangles more efficiently. :)
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.
----- "João Pais" jmmmpais@googlemail.com a écrit :
tcl/tk behaves very slowly for fast calls, such as when dragging an array
of considerable size, or a big group of objects? afaik this is something
that could be improved in the present platform, but how better could it be
when using another gui framework?
This is very slow because everything selected is moving, this method makes a very slow dragging, if a rectangle is drawn just to show up area of selection that is been moving, that would be very fluid, and it shouldn't so hard to implement. I guess it would even be possible to capture the selection as an image, so we would drag just an image, and then there would be no difference.
something like this:
<B1-motion> ---> capture area to move, copy in clipboard selected objects and args, build an image or a rectangle, delete the selection, and move the image or rectangle. <B1-Release> ---> delete the image or rectangle, and paste the selected object(s).
It might be a good idea to list the problems with tcl/tk so we can
weigh
them against the difficulty of using a different GUI toolkit. The
problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it
means
that (without prior planning) it's hard to take a patch you've been
working on at font size 10 and display it adequately over a
projector,
for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Patrice Colet colet.patrice@free.fr To: pd-list pd-list@iem.at Cc: András Murányi muranyia@gmail.com; Jonathan Wilkes jancsika@yahoo.com; João Pais jmmmpais@googlemail.com Sent: Friday, August 26, 2011 9:46 PM Subject: Re: [PD] [PD-dev] tkwidgets
----- "João Pais" jmmmpais@googlemail.com a écrit :
tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework?
This is very slow because everything selected is moving, this method makes a very slow dragging,
Create "Put" menu array, size 1000. Right-click "properties" and in the "Canvas Properties" dialog, set the
x size to 1000. Now you got an array consisting of 1000 separate rectangle items-- to confirm this type the following into the
tcl prompt (show the prompt using the last item in the "Help" menu):
foreach win [winfo children .] {foreach cwin [winfo children $win] {if {[winfo class $cwin] eq "Canvas"} {foreach item [$cwin find withtag all] {pdtk_post "[$cwin type $item]\n"}}}}
A _little_ sluggish, could be improved (actually it's slightly improved if you draw the points as polygons), but:
Now change the array size in the "Array Properties" dialog to 10000000. In the "Canvas Properties" dialog, change the x size to 10. Type the same code as above in the tcl prompt and notice now (if you're drawing the array elements as "points") you've only got 10 rectangles being drawn on the canvas.
The first example is a little annoying, but can be improved by changing the coords (possibly using a single tag for the entire array) rather than deleting and redrawing the array. The second example can't be blamed on tcl/tk and at large array sizes is _much_ more likely to cause audio dropouts*.
-Jonathan
- because you're never going to need to draw an array with more rectangles than what you have for screen width, which is at most a couple thousand, and even with an array that big it's not maxing out the cpu on my dual-core laptop.
if a rectangle is drawn just to show up area of selection that is been moving, that would be very fluid, and it shouldn't so hard to implement. I guess it would even be possible to capture the selection as an image, so we would drag just an image, and then there would be no difference.
something like this:
<B1-motion> ---> capture area to move, copy in clipboard selected objects and args, build an image or a rectangle, delete the selection, and move the image or rectangle. <B1-Release> ---> delete the image or rectangle, and paste the selected object(s).
It might be a good idea to list the problems with tcl/tk so we can
weigh
them against the difficulty of using a different GUI toolkit. The
problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it
means
that (without prior planning) it's hard to take a patch you've been
working on at font size 10 and display it adequately over a
projector,
for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Patrice Colet
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Patrice Colet colet.patrice@free.fr; pd-list pd-list@iem.at Cc: András Murányi muranyia@gmail.com; João Pais jmmmpais@googlemail.com Sent: Friday, August 26, 2011 10:46 PM Subject: Re: [PD] [PD-dev] tkwidgets
From: Patrice Colet colet.patrice@free.fr To: pd-list pd-list@iem.at Cc: András Murányi muranyia@gmail.com; Jonathan Wilkes
jancsika@yahoo.com; João Pais jmmmpais@googlemail.com
Sent: Friday, August 26, 2011 9:46 PM Subject: Re: [PD] [PD-dev] tkwidgets
----- "João Pais" jmmmpais@googlemail.com a écrit :
tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework?
This is very slow because everything selected is moving, this method makes a
very slow dragging,
Create "Put" menu array, size 1000. Right-click "properties" and in the "Canvas Properties" dialog, set the
x size to 1000. Now you got an array consisting of 1000 separate rectangle items-- to confirm this type the following into the
tcl prompt (show the prompt using the last item in the "Help" menu):
foreach win [winfo children .] {foreach cwin [winfo children $win] {if {[winfo class $cwin] eq "Canvas"} {foreach item [$cwin find withtag all] {pdtk_post "[$cwin type $item]\n"}}}}
A _little_ sluggish, could be improved (actually it's slightly improved if you draw the points as polygons), but:
Now change the array size in the "Array Properties" dialog to 10000000. In the "Canvas Properties" dialog, change the x size to 10. Type the same code as above in the tcl prompt and notice now (if you're drawing the array elements as "points") you've only got 10 rectangles being drawn on the canvas.
The first example is a little annoying, but can be improved by changing the coords (possibly using a single tag for the entire array) rather than deleting and redrawing the array. The second example can't be blamed on tcl/tk and at large array sizes is _much_ more likely to cause audio dropouts*.
-Jonathan
- because you're never going to need to draw an array with more rectangles
than what you have for screen width, which is at most a couple thousand, and even with an array that big it's not maxing out the cpu on my dual-core laptop.
Btw-- even for the size 1000 array above, part of the cpu usage and sluggishness is caused by whatever computations pd is doing before sending the message to the gui to create the next rectangle (see my message earlier in this thread). So my example isn't exactly comparing tcl/tk speed to pd computation speed-- it's more like comparing a slightly bad apple to a much worse apple. In both cases I think the significant "sluggishness" digits are due to whatever pd is doing between message sends.
-Jonathan
Btw-- even for the size 1000 array above, part of the cpu usage and
sluggishness is caused by whatever computations pd is doing before sending the message
to the gui to create the next rectangle (see my message earlier in this
thread). So my example isn't exactly comparing tcl/tk speed to pd computation speed--
it's more like comparing a slightly bad apple to a much worse apple. In both cases I
think the significant "sluggishness" digits are due to whatever pd is doing
between message sends.
while no one has time to work on the real problem behind (described by
Jonathan), I would suggest a hack solution: instead of a copy of an image
(as suggested by someone), just turn the display off while the selection
is moving? doesnt' solve the real issue, but avoids some
dropouts/slugishness.
Found the culprit in: g_template.c
in function
plot_vis: /* We're done with the outline; now draw all the points. This code is inefficient since the template has to be searched for drawing instructions for every last point. */
However, there are really two problems here:
- Sluggishness when moving a "Put" menu array with the mouse in editmode. Pd should really just move those
rectangle items that are already plotted-- plot_vis doesn't need to be called if the user is in the act of displacing the
graph.
Does pd-l2ork do that?
- Sluggishness when creating an array, or opening a subpatch with one inside, or plotting a signal using
[tabwrite~], or populating an array using [soundfile]. Making the code inside plot_vis more efficient would indeed
improve all of these issues, though I'm not sure how to do that.
-Jonathan
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Patrice Colet colet.patrice@free.fr; pd-list pd-list@iem.at; Jonathan Wilkes jancsika@yahoo.com Cc: András Murányi muranyia@gmail.com Sent: Saturday, August 27, 2011 5:44 AM Subject: Re: [PD] [PD-dev] tkwidgets
Btw-- even for the size 1000 array above, part of the cpu usage and
sluggishness is
caused by whatever computations pd is doing before sending the message to
the
gui to create the next rectangle (see my message earlier in this thread).
So my
example isn't exactly comparing tcl/tk speed to pd computation speed--
it's more like
comparing a slightly bad apple to a much worse apple. In both cases I
think the
significant "sluggishness" digits are due to whatever pd is doing
between message
sends.
while no one has time to work on the real problem behind (described by Jonathan), I would suggest a hack solution: instead of a copy of an image (as suggested by someone), just turn the display off while the selection is moving? doesnt' solve the real issue, but avoids some dropouts/slugishness.
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: András Murányi muranyia@gmail.com; pd-list pd-list@iem.at Sent: Friday, August 26, 2011 2:30 PM Subject: Re: [PD] [PD-dev] tkwidgets
On 2011-08-26 11:31, Jonathan Wilkes wrote:
It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are:
- difficult to implement a decent zoom function for a canvas
- can't display png without the Img library (included in 8.6)
- can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.)
I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.
- Because tcl/tk is an interpreted language it is a lot slower than a compiled
language: you have a script in ASCII that has to go through a processor that interprets the script to call a lower-level machine that actually does the work, while Qt is compiled so it does what you ask it directly, more or less.
If there are any GUI developers out there, I'd love to see a few comparisons between tk canvas and Qt graphics view-- say, moving a large number of rectangles with the mouse, or creating/destroying a bunch of polygons, and looking at memory/cpu usage.
-Jonathan
That has little to do with Tcl/Tk being slow. That has a lot more to
do with how Pd is implemented. It generates and sends raw Tcl to the
GUI, and if you are moving a lot of stuff, that means a lot of raw Tcl
needs to be generated, sent, parsed, and executed. That definitely
slows things down. In my tests, I saw that moving a big patch around
or animating a big array could send 1 megabyte of raw Tcl to the GUI
per second. Receiving, parsing, and executing 1 megabyte of code per
second is actually pretty good, IMHO.
What needs to happen is that Pd should call Tcl procs not send blocks
of raw Tcl.
.hc
On Aug 26, 2011, at 5:19 PM, João Pais wrote:
tcl/tk behaves very slowly for fast calls, such as when dragging an
array of considerable size, or a big group of objects? afaik this is
something that could be improved in the present platform, but how
better could it be when using another gui framework?It might be a good idea to list the problems with tcl/tk so we can
weigh them against the difficulty of using a different GUI
toolkit. The problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it
means that (without prior planning) it's hard to take a patch
you've been working on at font size 10 and display it adequately
over a projector, for example. (If there's a work around I'd like
to know it.) I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
That's an excellent example. In the case I just wrote about, using
Tcl's tag and move could reduce 500 KB/sec of Tcl code to 5KB/sec.
.hc
On Aug 26, 2011, at 9:46 PM, Patrice Colet wrote:
This is very slow because everything selected is moving, this method
makes a very slow dragging, if a rectangle is drawn just to show up area of selection that is
been moving, that would be very fluid, and it shouldn't so hard to implement. I guess it would even be
possible to capture the selection as an image, so we would drag just an image, and then there would be no
difference.something like this:
<B1-motion> ---> capture area to move, copy in clipboard selected
objects and args, build an image or a rectangle, delete the
selection, and move the image or rectangle. <B1-Release> ---> delete the image or rectangle, and paste the
selected object(s).----- "João Pais" jmmmpais@googlemail.com a écrit :
tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework?
It might be a good idea to list the problems with tcl/tk so we can
weigh
them against the difficulty of using a different GUI toolkit. The
problems I see are:
difficult to implement a decent zoom function for a canvas
can't display png without the Img library (included in 8.6)
can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it
means
that (without prior planning) it's hard to take a patch you've been
working on at font size 10 and display it adequately over a
projector,
for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with
tcl/tk >= 8.5 as the GUI.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Patrice Colet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Sun, 28 Aug 2011, Hans-Christoph Steiner wrote:
Receiving, parsing, and executing 1 megabyte of code per second is actually pretty good, IMHO. What needs to happen is that Pd should call Tcl procs not send blocks of raw Tcl.
How do you do that ?
DD has sys_mgui(), which operates at a level similar to binbuf_addv(), but constructs Tcl function calls. It still called sys_vgui() under the hood. However, if sys_vgui() had been completely replaced by sys_mgui(), then it would have become easy to replace that Tcl eval-based protocol by, for example, OSC-over-TCP.
But what do _you_ have in mind, specifically ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sep 3, 2011, at 2:37 PM, Mathieu Bouchard wrote:
On Sun, 28 Aug 2011, Hans-Christoph Steiner wrote:
Receiving, parsing, and executing 1 megabyte of code per second is
actually pretty good, IMHO. What needs to happen is that Pd should
call Tcl procs not send blocks of raw Tcl.How do you do that ?
DD has sys_mgui(), which operates at a level similar to
binbuf_addv(), but constructs Tcl function calls. It still called
sys_vgui() under the hood. However, if sys_vgui() had been
completely replaced by sys_mgui(), then it would have become easy to
replace that Tcl eval-based protocol by, for example, OSC-over-TCP.But what do _you_ have in mind, specifically ?
Here's a good example of what I mean: the drawing commands for
obj,msg, etc boxes should not be in 'pd'. 'pd' should tell 'pd-gui':
"draw an object on this canvas, at this x,y with these inlets and
outlets". "pd-gui" should also handle the mouse clicks, selection
coloration, change of line style from dashed to solid, etc. So
something like:
draw_object .x230ad0.c "osc~ 500" 10 500 inlet~ inlet outlet~
That would replace this block of raw Tcl:
.x230af0.c itemconfigure .x230af0.t230e90 -fill black
.x230af0.c itemconfigure .x230af0.t230e90R -fill black
.x230af0.c create rectangle 277 182 277 182 -tags x
.x230af0.c delete x
pdtk_undomenu .x230af0 paste no
pdtk_canvas_editmode .x230af0 1
.x230af0.c create line 146 134 174 134 174 151 146 151 146 134 -dash
"" -tags [list .x230af0.t230ba0R obj]
.x230af0.c create rectangle 146 150 153 151 -tags
[list .x230af0.t230ba0o0 outlet]
.x230af0.c create rectangle 146 134 153 136 -tags
[list .x230af0.t230ba0i0 inlet]
.x230af0.c create rectangle 167 134 174 136 -tags
[list .x230af0.t230ba0i1 inlet]
pdtk_text_new .x230af0.c {.x230af0.t230ba0 obj text} 148.000000
136.000000 {osc~ 500} 10 black
.x230af0.c itemconfigure .x230af0.t230ba0 -fill blue
.x230af0.c itemconfigure .x230af0.t230ba0R -fill blue
pdtk_canvas_getscroll .x230af0.c
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Sat, 3 Sep 2011, Hans-Christoph Steiner wrote:
Here's a good example of what I mean: the drawing commands for obj,msg, etc boxes should not be in 'pd'. 'pd' should tell 'pd-gui': "draw an object on this canvas, at this x,y with these inlets and outlets". "pd-gui" should also handle the mouse clicks, selection coloration, change of line style from dashed to solid, etc. So something like:
draw_object .x230ad0.c "osc~ 500" 10 500 inlet~ inlet outlet~
desiredata sends : change x9ad1038 x9acecc0 0 {#X obj 140 100 osc~ 500;} 2 1 1
this is not using sys_mgui(), though. I don't really remember why I decided to not use it. It's using the pd_upload() function in the server. The 4th argument is the line of the object as it would be written in a .pd file. the 5th and 6th arguments is the number of inlets and outlets, and the 7th argument means that the object is ok (no red dash). The first arg is the id of the object, the second arg is the id of the canvas, and the third arg is the index of the object (as used in #X connect).
This was for object updates, and was supposed to be replaced by something more efficient based on diffs. The other problem with uploading whole objects was that it didn't merge diffs, as has to happen when you move a slider that is currently receiving values or changing colour on its own, for example.
sys_mgui was meant for sending updates. You'd give an object id, then a selector, then an arg signature (like "fssfsffsf" to mean some combination of float and symbols, for example), then varargs. This assumed that the object id came first, as in most forms of object-oriented Tcl, and unlike plain procs.
the proc named «change» had to be a regular proc, because it's also responsible for creating the object if it does not exist, so that there isn't any special case for that, and then it couldn't be an instance method because the object might not exist yet.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list pd-list@iem.at; João Pais jmmmpais@googlemail.com Sent: Saturday, September 3, 2011 6:31 PM Subject: Re: [PD] [PD-dev] tkwidgets
On Sat, 3 Sep 2011, Hans-Christoph Steiner wrote:
Here's a good example of what I mean: the drawing commands for obj,msg,
etc boxes should not be in 'pd'. 'pd' should tell 'pd-gui': "draw an object on this canvas, at this x,y with these inlets and outlets". "pd-gui" should also handle the mouse clicks, selection coloration, change of line style from dashed to solid, etc. So something like:
draw_object .x230ad0.c "osc~ 500" 10 500 inlet~ inlet outlet~
desiredata sends : change x9ad1038 x9acecc0 0 {#X obj 140 100 osc~ 500;} 2 1 1
this is not using sys_mgui(), though. I don't really remember why I decided to not use it. It's using the pd_upload() function in the server. The 4th argument is the line of the object as it would be written in a .pd file. the 5th and 6th arguments is the number of inlets and outlets, and the 7th argument means that the object is ok (no red dash). The first arg is the id of the object, the second arg is the id of the canvas, and the third arg is the index of the object (as used in #X connect).
This was for object updates, and was supposed to be replaced by something more efficient based on diffs. The other problem with uploading whole objects was that it didn't merge diffs, as has to happen when you move a slider that is currently receiving values or changing colour on its own, for example.
sys_mgui was meant for sending updates. You'd give an object id, then a selector, then an arg signature (like "fssfsffsf" to mean some combination of float and symbols, for example), then varargs. This assumed that the object id came first, as in most forms of object-oriented Tcl, and unlike plain procs.
the proc named «change» had to be a regular proc, because it's also responsible for creating the object if it does not exist, so that there isn't any special case for that, and then it couldn't be an instance method because the object might not exist yet.
If you spent the same amount of time working on DD as you do writing about how DD works, you could spend a lot less time writing about how DD works, and a lot more time working on DD. :)
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2011/9/4 Jonathan Wilkes jancsika@yahoo.com
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list pd-list@iem.at; João Pais jmmmpais@googlemail.com Sent: Saturday, September 3, 2011 6:31 PM Subject: Re: [PD] [PD-dev] tkwidgets
On Sat, 3 Sep 2011, Hans-Christoph Steiner wrote:
Here's a good example of what I mean: the drawing commands for obj,msg,
etc boxes should not be in 'pd'. 'pd' should tell 'pd-gui': "draw an object on this canvas, at this x,y with these inlets and outlets". "pd-gui" should also handle the mouse clicks, selection coloration, change of line style from dashed to solid,
etc.
So something like:
draw_object .x230ad0.c "osc~ 500" 10 500 inlet~ inlet outlet~
desiredata sends : change x9ad1038 x9acecc0 0 {#X obj 140 100 osc~ 500;} 2 1 1
this is not using sys_mgui(), though. I don't really remember why I
decided
to not use it. It's using the pd_upload() function in the server. The 4th argument is the line of the object as it would be written in a .pd file.
the 5th
and 6th arguments is the number of inlets and outlets, and the 7th
argument
means that the object is ok (no red dash). The first arg is the id of the object, the second arg is the id of the canvas, and the third arg is the
index
of the object (as used in #X connect).
This was for object updates, and was supposed to be replaced by something
more
efficient based on diffs. The other problem with uploading whole objects
was
that it didn't merge diffs, as has to happen when you move a slider that
is
currently receiving values or changing colour on its own, for example.
sys_mgui was meant for sending updates. You'd give an object id, then a selector, then an arg signature (like "fssfsffsf" to mean some combination of float and symbols, for example), then varargs. This
assumed that
the object id came first, as in most forms of object-oriented Tcl, and
unlike
plain procs.
the proc named «change» had to be a regular proc, because it's also responsible for creating the object if it does not exist, so that there isn't any special case for that, and then it couldn't be an instance method because the object might not exist yet.
If you spent the same amount of time working on DD as you do writing about how DD works, you could spend a lot less time writing about how DD works, and a lot more time working on DD. :)
-Jonathan
Hold on... When Matju talks about how DD works it's *almost* like backporting from DD to Pd, and in this sense it's historic. And because of the incompatible licenses, it might be the only way to port from DD to Pd. Pst...! :O)
Andras
On Sun, 4 Sep 2011, András Murányi wrote:
Hold on... When Matju talks about how DD works it's *almost* like backporting from DD to Pd, and in this sense it's historic. And because of the incompatible licenses, it might be the only way to port from DD to Pd. Pst...! :O)
So, what are the licenses of DesireData ?
It's not like you really looked.
The server-side changes are under the same BSD license as Pd.
And no-one ever asked me for any license-change of any part of the client-side. It's not like anyone ever tried.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 3 Sep 2011, Jonathan Wilkes wrote:
If you spent the same amount of time working on DD as you do writing about how DD works, you could spend a lot less time writing about how DD works, and a lot more time working on DD. :)
Do you think that it would be enough for getting anywhere ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sep 4, 2011, at 1:33 PM, Mathieu Bouchard wrote:
On Sat, 3 Sep 2011, Jonathan Wilkes wrote:
If you spent the same amount of time working on DD as you do
writing about how DD works, you could spend a lot less time writing
about how DD works, and a lot more time working on DD. :)Do you think that it would be enough for getting anywhere ?
Yes.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
2011/9/4 Mathieu Bouchard matju@artengine.ca
On Sun, 4 Sep 2011, András Murányi wrote:
Hold on... When Matju talks about how DD works it's *almost* like
backporting from DD to Pd, and in this sense it's historic. And because of the incompatible licenses, it might be the only way to port from DD to Pd. Pst...! :O)
So, what are the licenses of DesireData ?
It's not like you really looked.
It's similar: I remembered. See the whole thread: http://lists.puredata.info/pipermail/pd-list/2010-10/083326.html So, my point was: instead of arriving once every year to this point of "oh it's not compatible licenses / oh they are / oh noone asked me / etc) and then going no further, it is actually pretty cool that you tell how things are in DD and why, and someone who understands it might go and code it up. This way any *possible* license incompatibilities, many *possible* bugs, and *possible* virii/malware are filtered out. The last one was a joke.
Andras
The server-side changes are under the same BSD license as Pd.
And no-one ever asked me for any license-change of any part of the client-side. It's not like anyone ever tried.
______________________________**______________________________** ___________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; pd-list pd-list@iem.at; João Pais jmmmpais@googlemail.com Sent: Sunday, September 4, 2011 1:33 PM Subject: Re: [PD] [PD-dev] tkwidgets
On Sat, 3 Sep 2011, Jonathan Wilkes wrote:
If you spent the same amount of time working on DD as you do writing about
how DD works, you could spend a lot less time writing about how DD works, and a lot more time working on DD. :)
Do you think that it would be enough for getting anywhere ?
Actually the problem I reported to you about the audio not working was on my end. So if the audio works, and the iemguis are functional, the main problem looks like the subpatch zombies/gop stuff (which I'm sure is not easy to solve). There are several small bugs on the tcl/tk side that I think I could fix easily. And if you set aside the tkzinc stuff for the time being, it looks like a lot of the functionality is already there.
It's just that I made a list of improvements I'd like to add to Pd, and nearly all of them are there in some degree of a functioning state in DD.
At the very least, would you be interested in throwing it up on github or somewhere? (I'm not even sure if I'm using the latest release.)
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
András Murányi -
Hans-Christoph Steiner -
Jonathan Wilkes -
João Pais -
Martin Peach -
Mathieu Bouchard -
Patrice Colet -
yvan volochine