[PD-dev] adding a built-in [change] object to the built-in GUI objects

Jonathan Wilkes jancsika at yahoo.com
Mon Dec 3 18:10:11 CET 2012





----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-dev at iem.at List" <pd-dev at 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 at.or.at>
>>>  To: "pd-dev at iem.at List" <pd-dev at 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&revision=16643
> 
> Then I did something similar for the [label ( draws:
> http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=0271c92082c6db85eccba0f0b1226b9dbff09ceb
> 
> .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 at iem.at
>>>  http://lists.puredata.info/listinfo/pd-dev
>>> 
> 



More information about the Pd-dev mailing list