Lots of patches use the built-in GUI objects for displays, and often a fast stream of events is hooked straight up to the GUI object, causing the GUI object to send many pointless updates, like draw commands when the number hasn't changed, or multiple draw commands per screen refresh cycle.
I propose to only send the GUI update commands when the relevant value has changed. I think this should apply to both the main element, like the slider knob, and the label for that GUI object, since that's often used as a display. The code change is pretty simple, but I was wondering if people thought there could be any problems caused by this
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val; + int x_prev_val; int x_center; int x_thick; int x_lin0_log1; index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client; - if (glist_isvisible(glist)) + if (glist_isvisible(glist) && x->x_val != x->x_prev_val) { int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val + 50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist); @@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist *glist) x->x_thick = 0; } } + x->x_prev_val = x->x_val; } }
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: "pd-dev@iem.at List" pd-dev@iem.at Cc: Sent: Friday, November 30, 2012 11:20 PM Subject: [PD-dev] adding a built-in [change] object to the built-in GUI objects
Lots of patches use the built-in GUI objects for displays, and often a fast stream of events is hooked straight up to the GUI object, causing the GUI object to send many pointless updates, like draw commands when the number hasn't changed, or multiple draw commands per screen refresh cycle.
The multiple draw commands per screen refresh cycle seems like the more common source of needless draw commands.
I propose to only send the GUI update commands when the relevant value has changed. I think this should apply to both the main element, like the slider knob, and the label for that GUI object, since that's often used as a display. The code change is pretty simple, but I was wondering if people thought there could be any problems caused by this
At the end of hslider_set, why not just check if x->x_value==(int)(100.0*g + 0.49999) before assigning it? If its already equal just return.
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val; + int x_prev_val; int x_center; int x_thick; int x_lin0_log1; index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client; - if (glist_isvisible(glist)) + if (glist_isvisible(glist) && x->x_val != x->x_prev_val) { int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val + 50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist); @@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist *glist) x->x_thick = 0; } } + x->x_prev_val = x->x_val; } }
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Dec 1, 2012, at 3:28 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: "pd-dev@iem.at List" pd-dev@iem.at Cc: Sent: Friday, November 30, 2012 11:20 PM Subject: [PD-dev] adding a built-in [change] object to the built-in GUI objects
Lots of patches use the built-in GUI objects for displays, and often a fast stream of events is hooked straight up to the GUI object, causing the GUI object to send many pointless updates, like draw commands when the number hasn't changed, or multiple draw commands per screen refresh cycle.
The multiple draw commands per screen refresh cycle seems like the more common source of needless draw commands.
That should be addressed too, but that's a lot more complicated. Honestly, I think it would be better to rewrite the basic GUI objects from scratch rather than put more into the current ones.
I propose to only send the GUI update commands when the relevant value has changed. I think this should apply to both the main element, like the slider knob, and the label for that GUI object, since that's often used as a display. The code change is pretty simple, but I was wondering if people thought there could be any problems caused by this
At the end of hslider_set, why not just check if x->x_value==(int)(100.0*g + 0.49999) before assigning it? If its already equal just return.
Good idea, that's what I ended up doing: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
Then I did something similar for the [label ( draws: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended....
.hc
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val;
- int x_prev_val; int x_center; int x_thick; int x_lin0_log1;
index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client;
- if (glist_isvisible(glist))
- if (glist_isvisible(glist) && x->x_val != x->x_prev_val) { int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val +
50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist); @@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist *glist) x->x_thick = 0; } }
x->x_prev_val = x->x_val;}
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at List" pd-dev@iem.at Sent: Monday, December 3, 2012 11:02 AM Subject: Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
On Dec 1, 2012, at 3:28 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: "pd-dev@iem.at List" pd-dev@iem.at Cc: Sent: Friday, November 30, 2012 11:20 PM Subject: [PD-dev] adding a built-in [change] object to the built-in GUI
objects
Lots of patches use the built-in GUI objects for displays, and often a
fast
stream of events is hooked straight up to the GUI object, causing the
GUI object
to send many pointless updates, like draw commands when the number
hasn't
changed, or multiple draw commands per screen refresh cycle.
The multiple draw commands per screen refresh cycle seems like the more
common
source of needless draw commands.
That should be addressed too, but that's a lot more complicated. Honestly, I think it would be better to rewrite the basic GUI objects from scratch rather than put more into the current ones.
It'd be even better to use a modern GUI toolkit that has simple tools to implement bleeding edge UX technology from the past 15 years. Stuff like hyperlinks. :)
-Jonathan
I propose to only send the GUI update commands when the relevant value
has
changed. I think this should apply to both the main element, like the
slider
knob, and the label for that GUI object, since that's often used as
a
display. The code change is pretty simple, but I was wondering if
people
thought there could be any problems caused by this
At the end of hslider_set, why not just check if
x->x_value==(int)(100.0*g + 0.49999)
before assigning it? If its already equal just return.
Good idea, that's what I ended up doing: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
Then I did something similar for the [label ( draws: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended....
.hc
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val; + int x_prev_val; int x_center; int x_thick; int x_lin0_log1; index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client; - if (glist_isvisible(glist)) + if (glist_isvisible(glist) && x->x_val !=
x->x_prev_val)
{ int r = text_xpix(&x->x_gui.x_obj, glist) +
(x->x_val +
50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist); @@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client,
t_glist
*glist) x->x_thick = 0; } } + x->x_prev_val = x->x_val; } }
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-03 18:10, Jonathan Wilkes wrote:
It'd be even better to use a modern GUI toolkit that has simple tools to implement bleeding edge UX technology from the past 15 years. Stuff like hyperlinks. :)
if hyperlinks is the criterion, then i don't see any problems with tcl/tk.
fgasdmr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Monday, December 3, 2012 12:13 PM Subject: Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-03 18:10, Jonathan Wilkes wrote:
It'd be even better to use a modern GUI toolkit that has simple tools to implement bleeding edge UX technology from the past 15 years. Stuff like hyperlinks. :)
if hyperlinks is the criterion, then i don't see any problems with tcl/tk.
It's not a binary matter. It's a question of whether I can describe a hyperlink with the tools that tcl/tk provides and not have to spend the same amount of time as I would in c to implement them.
Specifically-- tags in a tk canvas are per item while its the opposite in tk text widget. This isn't a difference between defaults for widgets, but incompatibility between them. It means in a canvas you can't easily set Enter/Leave events for a region made up of multiple polygons (which would require unmaintained tkzinc library), and alternately you can't easily define hyperlink Enter/Leave bindings in a text widget without ending up with accidental contiguous tag regions (two hyperlinks in a row, or one hyperlink above another on the next line).
Wrt to the Browser2.0 plugin, the straightforward workaround of a proc that defines a new tag name for each hyperlink would probably end up having performance issues since that could potentially be 1000s of unique tags per search. My specific workaround isn't pretty and I can improve it some, but it's still going to suffer from this problem.
-Jonathan
fgasdmr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlC83a4ACgkQkX2Xpv6ydvRrYwCg4GEd95Nns/+NYfxLTBwLL02y VckAoNH7DA9MPFwGcpfGYAXNohrI7Q8k =0weM -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I'd suggest cacheing the pixel value, not the value value. It's an easy fix and I can go through and do it while I'm waiting for other bugs to surface after trying to make all the 0.44-critical changes on the pile. (these are resolving my having broken the "new build system" in my impoartation of portaudio, and also finally acting on the hip~ and inlet~ bugs.)
cheers Miller
On Fri, Nov 30, 2012 at 11:20:53PM -0500, Hans-Christoph Steiner wrote:
Lots of patches use the built-in GUI objects for displays, and often a fast stream of events is hooked straight up to the GUI object, causing the GUI object to send many pointless updates, like draw commands when the number hasn't changed, or multiple draw commands per screen refresh cycle.
I propose to only send the GUI update commands when the relevant value has changed. I think this should apply to both the main element, like the slider knob, and the label for that GUI object, since that's often used as a display. The code change is pretty simple, but I was wondering if people thought there could be any problems caused by this
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val;
- int x_prev_val; int x_center; int x_thick; int x_lin0_log1;
index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client;
- if (glist_isvisible(glist))
- if (glist_isvisible(glist) && x->x_val != x->x_prev_val) { int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val + 50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist);
@@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist *glist) x->x_thick = 0; } }
x->x_prev_val = x->x_val;}
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
That's how I ended up implementing it, based on Jonathan's suggestion: http://sourceforge.net/tracker/?func=detail&aid=3591986&group_id=557...
.hc
On Dec 4, 2012, at 12:06 PM, Miller Puckette wrote:
I'd suggest cacheing the pixel value, not the value value. It's an easy fix and I can go through and do it while I'm waiting for other bugs to surface after trying to make all the 0.44-critical changes on the pile. (these are resolving my having broken the "new build system" in my impoartation of portaudio, and also finally acting on the hip~ and inlet~ bugs.)
cheers Miller
On Fri, Nov 30, 2012 at 11:20:53PM -0500, Hans-Christoph Steiner wrote:
Lots of patches use the built-in GUI objects for displays, and often a fast stream of events is hooked straight up to the GUI object, causing the GUI object to send many pointless updates, like draw commands when the number hasn't changed, or multiple draw commands per screen refresh cycle.
I propose to only send the GUI update commands when the relevant value has changed. I think this should apply to both the main element, like the slider knob, and the label for that GUI object, since that's often used as a display. The code change is pretty simple, but I was wondering if people thought there could be any problems caused by this
Here is the needed change, for example, for the hslider knob:
index b352fb9..88681fc 100644 --- a/src/g_all_guis.h +++ b/src/g_all_guis.h @@ -185,6 +185,7 @@ typedef struct _hslider t_iemgui x_gui; int x_pos; int x_val;
- int x_prev_val; int x_center; int x_thick; int x_lin0_log1;
index 470771a..e1a3c83 100644 --- a/src/g_hslider.c +++ b/src/g_hslider.c @@ -33,7 +33,7 @@ static t_class *hslider_class; static void hslider_draw_update(t_gobj *client, t_glist *glist) { t_hslider *x = (t_hslider *)client;
- if (glist_isvisible(glist))
- if (glist_isvisible(glist) && x->x_val != x->x_prev_val) { int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val + 50)/100; int ypos=text_ypix(&x->x_gui.x_obj, glist);
@@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist *glist) x->x_thick = 0; } }
x->x_prev_val = x->x_val;}
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Miller Puckette