Even tho the screen updates at least evern 16ms, most GUI object do
not benefit from that at all. For example, number boxes would be
totally fine updating every 100ms or more, unless you like the look
of blurry numbers flying by. Sliders and buttons probably would be
fine at 50ms also
It
for what its worth, Max has a preference that sets the frequency of
all screen refreshes of patcher objects. This can be useful to reduce
GUI overhead on heavy patches.
On Nov 3, 2007, at 5:05 PM, João Miguel Pais wrote:
Even tho the screen updates at least evern 16ms, most GUI object do
On Nov 1, 2007, at 1:06 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often
than once
per frame on the viewing device, but of course that signal (the
vertical
retrace or frame sync) is
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often than once
per frame on the viewing device, but of course that signal (the vertical
retrace or frame sync) is often hard to obtain. openGL sometimes has it
builtin, does tk? 60Hz is
Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often than once
per frame on the viewing device, but of course that signal (the vertical
retrace or frame sync) is often hard to obtain. openGL sometimes has it
builtin,
On Nov 1, 2007, at 12:20 PM, Mathieu Bouchard wrote:
On Thu, 1 Nov 2007, Martin Peach wrote:
It doesn't make sense to update a box or the screen more often
than once per frame on the viewing device, but of course that
signal (the vertical retrace or frame sync) is often hard to
For the gui-edit patch that I made some time ago to work perfectly, a
state query command would be necessary. Then it would be possible to
send the properties of each element to pd, and do whatever you want with
it.
How about also checking out if there would be any other alternative to
How about also checking out if there would be any other alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like
a gui element in a gop) take lots of cpu for what they give.
a lot of this has nothing to do with TCL/Tk being slow, but PD using C string
On Wed, 31 Oct 2007, João Miguel Pais wrote:
How about also checking out if there would be any other alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated things
(like a gui element in a gop) take lots of cpu for what they give.
I think that it's easier to work on
On Wed, 31 Oct 2007, cdr wrote:
How about also checking out if there would be any other alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated things (like
a gui element in a gop) take lots of cpu for what they give.
a lot of this has nothing to do with TCL/Tk being slow,
On Oct 31, 2007, at 12:51 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, cdr wrote:
How about also checking out if there would be any other
alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated
things (like
a gui element in a gop) take lots of cpu for what they
On Oct 31, 2007, at 4:45 AM, cdr wrote:
How about also checking out if there would be any other
alternative to
Tcl/Tk? It's still quite slow, and some not so uncomplicated
things (like
a gui element in a gop) take lots of cpu for what they give.
a lot of this has nothing to do with
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance improvements,
especially on Mac OS X, as it shifts from Carbon/QuickDraw to
Cocoa/CoreGraphics.
I said that before. I'm claiming that Tcl/Tk 8.5 is too slow. Tcl/Tk 8.4
is even
On Oct 31, 2007, at 3:12 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance
improvements, especially on Mac OS X, as it shifts from Carbon/
QuickDraw to Cocoa/CoreGraphics.
I said that before. I'm
The state query is a very good idea, feel like adding it to the wiki? :)
.hc
On Oct 31, 2007, at 8:26 AM, João Miguel Pais wrote:
For the gui-edit patch that I made some time ago to work perfectly,
a state query command would be necessary. Then it would be
possible to send the
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
This is not where the bottleneck is.
I thought the network socket was the bottleneck. The example I am thinking
of is getting the mouse pointer coords from Tk. That generates a lot of
network traffic, it would be nice this happened in the pd
Hans-Christoph Steiner wrote:
On Oct 31, 2007, at 3:12 PM, Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Hans-Christoph Steiner wrote:
First off, Tcl/Tk 8.5 looks to have a lot of performance
improvements, especially on Mac OS X, as it shifts from Carbon/
QuickDraw to Cocoa/CoreGraphics.
On Wed, 31 Oct 2007, Martin Peach wrote:
Maybe if redundant calls could be pruned before going through the socket
things would work better. For instance if a number box is being updated
a few hundred times a second then it would be better if only the last
update per signal block would get
Mathieu Bouchard wrote:
On Wed, 31 Oct 2007, Martin Peach wrote:
Maybe if redundant calls could be pruned before going through the
socket things would work better. For instance if a number box is
being updated a few hundred times a second then it would be better if
only the last update
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc
this, join in! The next thing to for GUIs after this is to extend
tclpd so that you can write totally custom GUI objects completely in
is there something wrong with the [widget] external that made you want to
reinvent
On Oct 30, 2007, at 5:01 AM, cdr wrote:
http://puredata.info/dev/TkWidget
Please add ideas, comments, etc
this, join in! The next thing to for GUIs after this is to extend
tclpd so that you can write totally custom GUI objects completely in
is there something wrong with the [widget]
21 matches
Mail list logo
