hey folks,
the new UI in 0.40-3 extended looks super nice - but on my machine (dual i386 2.0Ghz / MacOsx 10.4) it seriously degrades UI performance, especially with Graph on Parent objects.
for example, loading a small GOP abstraction with four bang buttons, two checkboxes, a number box, a slider and a vu meter takes a noticeable amount of time with 0.40.3-extended, but happens instantaneously with 0.40.2-vanilla. dragging this abstraction around the window suffers as well: on 0.40.3-extended when dragging this object the performance drops down to about 10fps, whereas on 0.40.2-vanilla i can drag at what seems to be the full framerate of my system (there's a bit of mouse lag though).
it seems such a shame, because it really is much nicer to work with, visually, but the sluggishness when i get sizeable patches going is going to keep me on 0.40.2-vanilla with its old fashiouned ui. i assume the culprit is Tcl/Tk. i ask again: why are we using Tcl/Tk to implement the UI part of a **graphical** dataflow language? Tcl/Tk is a user-interface toolkit, but we're asking it be a graphics platform, and it just can't hack it.
Other people have reported this, but I haven't been able to reproduce
it. Please create a bug report in the tracker and submit an example
patch. (For whatever reason, no one has done that yet, despite my
requests). Then I'll take a look at it.
.hc
On Jun 28, 2008, at 11:20 PM, Damian Stewart wrote:
hey folks,
the new UI in 0.40-3 extended looks super nice - but on my machine
(dual i386 2.0Ghz / MacOsx 10.4) it seriously degrades UI performance,
especially with Graph on Parent objects.for example, loading a small GOP abstraction with four bang
buttons, two checkboxes, a number box, a slider and a vu meter takes a
noticeable amount of time with 0.40.3-extended, but happens instantaneously with 0.40.2-vanilla. dragging this abstraction around the window suffers as well: on 0.40.3-extended when dragging this object the performance
drops down to about 10fps, whereas on 0.40.2-vanilla i can drag at what
seems to be the full framerate of my system (there's a bit of mouse lag
though).it seems such a shame, because it really is much nicer to work with, visually, but the sluggishness when i get sizeable patches going is
going to keep me on 0.40.2-vanilla with its old fashiouned ui. i assume the culprit is Tcl/Tk. i ask again: why are we using Tcl/Tk to
implement the UI part of a **graphical** dataflow language? Tcl/Tk is a user-interface toolkit, but we're asking it be a graphics platform, and it just
can't hack it.-- damian stewart | +31 6 5902 5782 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hans-Christoph Steiner wrote:
Other people have reported this, but I haven't been able to reproduce it. Please create a bug report in the tracker and submit an example patch. (For whatever reason, no one has done that yet, despite my requests). Then I'll take a look at it.
bug submitted - request id 2005761
Hans-Christoph Steiner wrote:
Other people have reported this, but I haven't been able to reproduce it. Please create a bug report in the tracker and submit an example patch. (For whatever reason, no one has done that yet, despite my requests). Then I'll take a look at it.
are you on Linux? the problem probably won't show up on Linux, because of the relationship between Tk and Xlib:
(from the website of the TkGS project http://membres.lycos.fr/fbonnet/Tcl/TkGS/introduction.htm , sadly stalled since 2000)
"So what is the problem with the XLEL? Porting part of the Xlib to new platforms was a good idea in the beginning because it allowed for easier porting of the many existent Tk applications. The counterpart is that one had to use the Xlib graphics model on all platforms to remain portable, and that is the main cause of the XLEL inadequacy: bad performances. Tk is notably slower on platforms other than native X-Window systems. But this lack of performance is not due to the XLEL itself, but to the way it uses the native graphics system. The Xlib uses a fundamentally stateless model, whereas Windows and MacOS use state-based models.
"For example, to draw a shape, a Xlib application calls a drawing primitive such as XDrawRectangle() and passes the drawing parameters as arguments in the form of a Graphics Context (GC), a structure that contains all the drawing parameters such as foreground color or font. On Windows, one has first to create objects such as brushes, pens, fonts, then select these objets that will be used by all the subsequent primitives such as Rectangle(). These objects are selected into a Device Context (DC) that has to be created before any drawing and released after, holding the state in the meantime. These operations are costy and thus should be done once for all before any primitive is called. Besides, since they are available in rather limited resources, one has to be careful to free them all once the drawing operation is complete.
"Since The Xlib uses a stateless model, the XLEL has no choice but to re-create a valid drawing context (eg. a DC on Windows) from its GC values at every drawing operation. That way, costy operations that were intended to be called once before any number of drawing primitives (ie in O(1) time), are called for every primitive (ie in O(n) time), even if the drawing parameters are the same. Thus the relatively bad performances of Windows and MacOS Tk (even on the same hardware). A solution would be to use caching schemes to avoid useless re-creation of drawing structures. Leo Schubert's speedpatch for Tk 8.0 uses this kind of technique (it stores the internal GDI objects into the GC structure). Although the results are impressive in term of performances, these techniques have several drawbacks: ..."
On Jun 29, 2008, at 11:56 AM, Damian Stewart wrote:
Hans-Christoph Steiner wrote:
Other people have reported this, but I haven't been able to
reproduce it. Please create a bug report in the tracker and
submit an example patch. (For whatever reason, no one has done
that yet, despite my requests). Then I'll take a look at it.are you on Linux? the problem probably won't show up on Linux,
because of the relationship between Tk and Xlib:
I use Ubuntu, Debian, and Mac OS X. TkGS isn't really relevant
anymore. With Tcl/Tk 8.5 has big improvements on Mac OS X, I believe
they completed the port from the old Carbon graphics to the current
CoreGraphics.
Thanks for the bug report!
.hc
(from the website of the TkGS project http://membres.lycos.fr/fbonnet/Tcl/TkGS/introduction.htm , sadly
stalled since 2000)"So what is the problem with the XLEL? Porting part of the Xlib to
new platforms was a good idea in the beginning because it allowed
for easier porting of the many existent Tk applications. The
counterpart is that one had to use the Xlib graphics model on all
platforms to remain portable, and that is the main cause of the
XLEL inadequacy: bad performances. Tk is notably slower on
platforms other than native X-Window systems. But this lack of
performance is not due to the XLEL itself, but to the way it uses
the native graphics system. The Xlib uses a fundamentally stateless
model, whereas Windows and MacOS use state-based models."For example, to draw a shape, a Xlib application calls a drawing
primitive such as XDrawRectangle() and passes the drawing
parameters as arguments in the form of a Graphics Context (GC), a
structure that contains all the drawing parameters such as
foreground color or font. On Windows, one has first to create
objects such as brushes, pens, fonts, then select these objets that
will be used by all the subsequent primitives such as Rectangle().
These objects are selected into a Device Context (DC) that has to
be created before any drawing and released after, holding the state
in the meantime. These operations are costy and thus should be done
once for all before any primitive is called. Besides, since they
are available in rather limited resources, one has to be careful to
free them all once the drawing operation is complete."Since The Xlib uses a stateless model, the XLEL has no choice but
to re-create a valid drawing context (eg. a DC on Windows) from its
GC values at every drawing operation. That way, costy operations
that were intended to be called once before any number of drawing
primitives (ie in O(1) time), are called for every primitive (ie in
O(n) time), even if the drawing parameters are the same. Thus the
relatively bad performances of Windows and MacOS Tk (even on the
same hardware). A solution would be to use caching schemes to avoid
useless re-creation of drawing structures. Leo Schubert's
speedpatch for Tk 8.0 uses this kind of technique (it stores the
internal GDI objects into the GC structure). Although the results
are impressive in term of performances, these techniques have
several drawbacks: ..."-- damian stewart | +31 6 5902 5782 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Access to computers should be unlimited and total. - the hacker ethic
Also, I forgot to mention, could you try a very old auto-build to see
if that has the same slowness:
http://autobuild.puredata.info/auto-build/
If you find that the oldest is not slow, then narrowing down the date
range would help a lot.
.hc
On Jun 28, 2008, at 11:20 PM, Damian Stewart wrote:
hey folks,
the new UI in 0.40-3 extended looks super nice - but on my machine
(dual i386 2.0Ghz / MacOsx 10.4) it seriously degrades UI performance,
especially with Graph on Parent objects.for example, loading a small GOP abstraction with four bang
buttons, two checkboxes, a number box, a slider and a vu meter takes a
noticeable amount of time with 0.40.3-extended, but happens instantaneously with 0.40.2-vanilla. dragging this abstraction around the window suffers as well: on 0.40.3-extended when dragging this object the performance
drops down to about 10fps, whereas on 0.40.2-vanilla i can drag at what
seems to be the full framerate of my system (there's a bit of mouse lag
though).it seems such a shame, because it really is much nicer to work with, visually, but the sluggishness when i get sizeable patches going is
going to keep me on 0.40.2-vanilla with its old fashiouned ui. i assume the culprit is Tcl/Tk. i ask again: why are we using Tcl/Tk to
implement the UI part of a **graphical** dataflow language? Tcl/Tk is a user-interface toolkit, but we're asking it be a graphics platform, and it just
can't hack it.-- damian stewart | +31 6 5902 5782 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Hans-Christoph Steiner wrote:
Also, I forgot to mention, could you try a very old auto-build to see if that has the same slowness:
http://autobuild.puredata.info/auto-build/
If you find that the oldest is not slow, then narrowing down the date range would help a lot.
i just downloaded the oldest i could find with an OSX/Intel build (2008-01-08) and got exactly the same problem.
-
Damian Stewart -
Hans-Christoph Steiner