Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
That's how I ended up implementing it, based on Jonathan's suggestion:
http://sourceforge.net/tracker/?func=detail&aid=3591986&group_id=55736&atid=478072
.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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
- Original Message - > From: IOhannes m zmoelnig > 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 > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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. 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
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
- Original Message -
> From: Hans-Christoph Steiner
> To: Jonathan Wilkes
> Cc: "pd-dev@iem.at List"
> 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
>>> To: "pd-dev@iem.at List"
>>> 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.4)
>> 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@iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
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
>> To: "pd-dev@iem.at List"
>> 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.4)
> 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@iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
- Original Message -
> From: Hans-Christoph Steiner
> To: "pd-dev@iem.at List"
> 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.4)
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
>
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
