Modal stacks cpu usage

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Modal stacks cpu usage

Paul Dupuis via use-livecode
I have just noticed something curious.

I am running LiveCode 8.1 IDE 9.6.1 on a Mac Air 2020 quad core Catalina.  

Typically LC cpu usage shows about 34%  (presumably of 1 core).  When a modal stack is opened it immediately ramps up to 99% ; the fan kicks in, and if left for a while the OS boosts the kernel_task daemon which I have been told is a protection device to prevent overheating. This has the effect of very markedly slowing down all apps as they get less cpu time.

If the stack is opened in non-modal mode, cpu usage stays around 34% . I don’t understand why a modal stack should be a cpu hog, indeed it seems like a bug to me.

I have a suspicion the wait with messages command  may have the same effect on cpu performance, so it could be the culprit.





_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
Another factor I discovered in times past (which may have been changed
by now) that eats up CPU cycles is the "Default" button style. Do you
possibly have one of those on your stack?

Phil Davis


On 9/30/20 7:30 PM, Neville Smythe via use-livecode wrote:

> I have just noticed something curious.
>
> I am running LiveCode 8.1 IDE 9.6.1 on a Mac Air 2020 quad core Catalina.
>
> Typically LC cpu usage shows about 34%  (presumably of 1 core).  When a modal stack is opened it immediately ramps up to 99% ; the fan kicks in, and if left for a while the OS boosts the kernel_task daemon which I have been told is a protection device to prevent overheating. This has the effect of very markedly slowing down all apps as they get less cpu time.
>
> If the stack is opened in non-modal mode, cpu usage stays around 34% . I don’t understand why a modal stack should be a cpu hog, indeed it seems like a bug to me.
>
> I have a suspicion the wait with messages command  may have the same effect on cpu performance, so it could be the culprit.
>
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Phil Davis
503-307-4363


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
Sorry Neville, I didn't read your email closely enough - you are
obviously on the right track.

Phil


On 9/30/20 9:02 PM, Phil Davis via use-livecode wrote:

> Another factor I discovered in times past (which may have been changed
> by now) that eats up CPU cycles is the "Default" button style. Do you
> possibly have one of those on your stack?
>
> Phil Davis
>
>
> On 9/30/20 7:30 PM, Neville Smythe via use-livecode wrote:
>> I have just noticed something curious.
>>
>> I am running LiveCode 8.1 IDE 9.6.1 on a Mac Air 2020 quad core
>> Catalina.
>>
>> Typically LC cpu usage shows about 34%  (presumably of 1 core). When
>> a modal stack is opened it immediately ramps up to 99% ; the fan
>> kicks in, and if left for a while the OS boosts the kernel_task
>> daemon which I have been told is a protection device to prevent
>> overheating. This has the effect of very markedly slowing down all
>> apps as they get less cpu time.
>>
>> If the stack is opened in non-modal mode, cpu usage stays around 34%
>> . I don’t understand why a modal stack should be a cpu hog, indeed it
>> seems like a bug to me.
>>
>> I have a suspicion the wait with messages command  may have the same
>> effect on cpu performance, so it could be the culprit.
>>
>>
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>

--
Phil Davis
503-307-4363


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Neville Smythe wrote:

 > Typically LC cpu usage shows about 34%  (presumably of 1 core).  When
 > a modal stack is opened it immediately ramps up to 99% ; the fan kicks
 > in, and if left for a while the OS boosts the kernel_task daemon which
 > I have been told is a protection device to prevent overheating. This
 > has the effect of very markedly slowing down all apps as they get less
 > cpu time.
 >
 > If the stack is opened in non-modal mode, cpu usage stays around 34% .
 > I don’t understand why a modal stack should be a cpu hog, indeed it
 > seems like a bug to me.

Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic
with modal dialogs.

I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the
problem there.

Have you opened a bug report on this?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
I’ll weigh in here. I have noticed at times my Mac becoming slow and extremely laggy to input. Quitting all my apps, including LC seems to resolve it, although I never dug in any deeper. (Honestly I thought it was a Chrome or web page issue and I am used to those.) Next time I see the issue I will dig further.

Bob S


On Oct 1, 2020, at 9:28 AM, Richard Gaskin via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

Neville Smythe wrote:

> Typically LC cpu usage shows about 34%  (presumably of 1 core).  When
> a modal stack is opened it immediately ramps up to 99% ; the fan kicks
> in, and if left for a while the OS boosts the kernel_task daemon which
> I have been told is a protection device to prevent overheating. This
> has the effect of very markedly slowing down all apps as they get less
> cpu time.
>
> If the stack is opened in non-modal mode, cpu usage stays around 34% .
> I don’t understand why a modal stack should be a cpu hog, indeed it
> seems like a bug to me.

Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic with modal dialogs.

I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the problem there.

Have you opened a bug report on this?

--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
> Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic
> with modal dialogs.
>
> I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the
> problem there.


Thanks Richard for confirming, and testing on Linux. Yes I will file a bug report.

It occurred to me that LC shouldn’t be using as much as 34% cpu when it is just idling anyway, even when not running a modal stack. Testing just now shows that is down to around 16%; of course LC’s time share will depend on lots of OS factors and other running apps, but that’s still way too high for an app supposedly doing nothing but waiting for events. Turning off the Rinaldi revSmartSave plugin brings it down to between 4 and 7%, which is more reasonable; presumably something to do with displaying its progress bar, perhaps another wait side effect.

Neville Smythe
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Looks like Elanor beat me to it Bug 22929 <https://quality.livecode.com/show_bug.cgi?id=22929>

Neville Smythe
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
If the Project Browser is open, try closing it. On my Mac, the CPU usage
while idle is usually close to 0 when in the background.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On October 2, 2020 7:03:59 PM Neville Smythe via use-livecode
<[hidden email]> wrote:

>> Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic
>> with modal dialogs.
>>
>> I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the
>> problem there.
>
>
> Thanks Richard for confirming, and testing on Linux. Yes I will file a bug
> report.
>
> It occurred to me that LC shouldn’t be using as much as 34% cpu when it is
> just idling anyway, even when not running a modal stack. Testing just now
> shows that is down to around 16%; of course LC’s time share will depend on
> lots of OS factors and other running apps, but that’s still way too high
> for an app supposedly doing nothing but waiting for events. Turning off the
> Rinaldi revSmartSave plugin brings it down to between 4 and 7%, which is
> more reasonable; presumably something to do with displaying its progress
> bar, perhaps another wait side effect.
>
> Neville Smythe
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Jacque wrote
> If the Project Browser is open, try closing it. On my Mac, the CPU usage
> while idle is usually close to 0 when in the background.

Interesting. I would indeed have expected a good-citizen app doing nothing in the background to use less than 1% cpu: Mail, Safari. Finder, BBEdit, Keyboard Maestro are currently all close to 0% But I never see LC using less than 4.3% with no user stacks open, no palettes, no plugins, no scripts, just the IDE. Adding revSmartSave brings it up to 15%. The only odd thing about the process I can see is the unusually high number of “idle wake ups”, sometimes over 100 in the Activity Monitor sampling period: no other process excepting kernel_task has anything like this number.

Of course it’s a mug’s game — if that is a phrase in your neck of the woods— trying to second guess OS time-sharing parameters, but it does look like LC is not a very nice (pun intended) citizen at least in this configuration: Catalina 10.15.6, Mac Air 2020 quad core, LC 9.6.1 Community!

Neville





_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
On 10/3/20 8:36 PM, Neville Smythe via use-livecode wrote:
> Jacque wrote
>> If the Project Browser is open, try closing it. On my Mac, the CPU usage
>> while idle is usually close to 0 when in the background.
>
> Interesting. I would indeed have expected a good-citizen app doing nothing in the background to use less than 1% cpu: Mail, Safari. Finder, BBEdit, Keyboard Maestro are currently all close to 0% But I never see LC using less than 4.3% with no user stacks open, no palettes, no plugins, no scripts, just the IDE.

I just checked again with LC 9.6.1, because the last time I looked was with a previous version.
With no open stacks of my own and only the Application Browser open, it hovers around 2%. When
I closed the App Browser, it dropped to about 1.5% and then hovered in the 1.5-2.0 range. While
writing this email it jumped to 3.5% momentarily, then dropped back to 2.5%.

I'm still on Mojave if that matters. I'm fairly sure the IDE is sending some pending messages
in the background which would account for the CPU usage.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Modal stacks cpu usage

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Indeed, when I open the Message box and click the Pending messages tab, two messages always keep running there:
_EnsureAccept (seems to have to do with the remote debugger library?)
_revInternal_SavePreferences

Just LC 9.6.1 running, no stacks. I’m also on Mojave.


J. Landman Gay via use-livecode <https://www.mail-archive.com/search?l=use-livecode@...&q=from:%22J.+Landman+Gay+via+use%5C-livecode%22> Mon, 05 Oct 2020 10:02:14 -0700 <https://www.mail-archive.com/search?l=use-livecode@...&q=date:20201005>
> I'm fairly sure the IDE is sending some pending messages
> in the background which would account for the CPU usage.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Canvas Limited to 32767

Paul Dupuis via use-livecode
I just ran head first into this. Could someone explain why other than moving from an int16 to an int32 this is such a challenge? This should have been addressed during the refactoring of the engine.

Inquiring minds want to know. Thanks for any info on this. Now I have some refactoring to do...

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Canvas Limited to 32767

Paul Dupuis via use-livecode
Ralph DiMola wrote:

 > I just ran head first into this. Could someone explain why other than
 > moving from an int16 to an int32 this is such a challenge? This should
 > have been addressed during the refactoring of the engine.

Is this for the weird recommended mobile workaround of putting a text
field into a group just to have it scroll, or something else?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Canvas Limited to 32767

Paul Dupuis via use-livecode
Desktop and mobile. It's a scrolling group with many sub-groups each with 1
or more fields. Sometimes the height of the main group > 32767.

It's the result of a proximity search and in dense areas users are getting
hosed by this limit. Customer is screaming (but don't they always).

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf
Of Richard Gaskin via use-livecode
Sent: Tuesday, October 06, 2020 2:01 PM
To: [hidden email]
Cc: Richard Gaskin
Subject: Re: Canvas Limited to 32767

Ralph DiMola wrote:

 > I just ran head first into this. Could someone explain why other than  >
moving from an int16 to an int32 this is such a challenge? This should  >
have been addressed during the refactoring of the engine.

Is this for the weird recommended mobile workaround of putting a text field
into a group just to have it scroll, or something else?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Canvas Limited to 32767

Paul Dupuis via use-livecode
You would think with 32K px at 72px/inch being like 450 inches that the
32K limit would not be an issue, but I have run into it as well

I have written a custom graph (like a bar graph for example sake) that
is generally fine with most customer data. However, on one customer data
set it started blowing up. It turns out that one of the bars was "huge"
(an the order of 400k px) at the zoom level where they could see the
details in the remaining bars. So, in this case the researchers wanted
to "zoom" in on noise in a larger data set, causing that larger data to
become huge in a graph.

And yes, you can code in bounds limits and attaching labels to indicate
a bar is out of bound or exceeds display area, etc., but I do agree that
for a number of applications having a large drawing area would be a big
improvement.


On 10/6/2020 2:28 PM, Ralph DiMola via use-livecode wrote:

> Desktop and mobile. It's a scrolling group with many sub-groups each with 1
> or more fields. Sometimes the height of the main group > 32767.
>
> It's the result of a proximity search and in dense areas users are getting
> hosed by this limit. Customer is screaming (but don't they always).
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> [hidden email]
>
>
> -----Original Message-----
> From: use-livecode [mailto:[hidden email]] On Behalf
> Of Richard Gaskin via use-livecode
> Sent: Tuesday, October 06, 2020 2:01 PM
> To: [hidden email]
> Cc: Richard Gaskin
> Subject: Re: Canvas Limited to 32767
>
> Ralph DiMola wrote:
>
>   > I just ran head first into this. Could someone explain why other than  >
> moving from an int16 to an int32 this is such a challenge? This should  >
> have been addressed during the refactoring of the engine.
>
> Is this for the weird recommended mobile workaround of putting a text field
> into a group just to have it scroll, or something else?
>
> --
>    Richard Gaskin
>    Fourth World Systems
>    Software Design and Development for the Desktop, Mobile, and the Web
>    ____________________________________________________________________
>    [hidden email]                http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Canvas Limited to 32767

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Glad it's not the funky mobile field workaround.  That's such a horrible
experience for developers that even the act of documenting it should
have been a red flag to go back and refine the field buffering for the
few cases where that put-it-in-a-group recommendation is actually needed.

In your case, you have a huuuuuuge canvas, with users expected to scroll
a region about 32 feet.  That's a lot of scrolling.

So in addition to the memory hit of buffering such a large region (32767
* 32767 * 4 + whatever other overhead comes into play with buffering),
in most layouts it would be a usability impairment to ask users to keep
scrolling that much.

So maybe the team could switch the address from 32 to 64, but it still
leave us with the question:

- Would a user have that much RAM?

- Would the user be able to use such a large canvas without acquiring
   RSI? ;)

I don't know your layout, but I do know you, and you're not the type to
make things hard for users, so I'm assuming there's something about this
uncommonly-large scrolling that fits well with the app's requirements.

But what we do know is no monitor can show it all, so the content is
already effectively paged into view as-needed.

Could the content paging be provided through some other UI? For example,
if those controls fit into logical groupings, might different sets of
them be placed into separate physical groups, perhaps accessed via tabs
or a list?

If it's truly necessary to have one vast plane to hold everything, could
you handle paging internally while still providing the appearance of a
contiguous group, similar to how the DataGrid does it?

--
  Richard Gaskin
  Fourth World Systems



Ralph DiMola wrote:
 > Desktop and mobile. It's a scrolling group with many sub-groups each
 > with 1 or more fields. Sometimes the height of the main group > 32767.
 >
 > It's the result of a proximity search and in dense areas users are
 > getting hosed by this limit. Customer is screaming (but don't they
 > always).
 >
 > Ralph DiMola
 > IT Director


-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On
Behalf
Of Richard Gaskin via use-livecode

Ralph DiMola wrote:

 > I just ran head first into this. Could someone explain why other than
   > moving from an int16 to an int32 this is such a challenge? This
should  > have been addressed during the refactoring of the engine.

Is this for the weird recommended mobile workaround of putting a text
field into a group just to have it scroll, or something else?

--
   Richard Gaskin
   Fourth World Systems


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Canvas Limited to 32767

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Paul,

I agree the it seems that 32767 would be more than enough but alas reality
intrudes. On desktop you can easily get to the bottom and on mobile a few
flicks will get you to the bottom. I use the same code(LC server) for the
http html version and there is no problem there when the search returns an
obscene number of results.

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf
Of Paul Dupuis via use-livecode
Sent: Tuesday, October 06, 2020 2:39 PM
To: [hidden email]
Cc: Paul Dupuis
Subject: Re: Canvas Limited to 32767

You would think with 32K px at 72px/inch being like 450 inches that the 32K
limit would not be an issue, but I have run into it as well

I have written a custom graph (like a bar graph for example sake) that is
generally fine with most customer data. However, on one customer data set it
started blowing up. It turns out that one of the bars was "huge"
(an the order of 400k px) at the zoom level where they could see the details
in the remaining bars. So, in this case the researchers wanted to "zoom" in
on noise in a larger data set, causing that larger data to become huge in a
graph.

And yes, you can code in bounds limits and attaching labels to indicate a
bar is out of bound or exceeds display area, etc., but I do agree that for a
number of applications having a large drawing area would be a big
improvement.


On 10/6/2020 2:28 PM, Ralph DiMola via use-livecode wrote:
> Desktop and mobile. It's a scrolling group with many sub-groups each
> with 1 or more fields. Sometimes the height of the main group > 32767.
>
> It's the result of a proximity search and in dense areas users are
> getting hosed by this limit. Customer is screaming (but don't they
always).

>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> [hidden email]
>
>
> -----Original Message-----
> From: use-livecode [mailto:[hidden email]] On
> Behalf Of Richard Gaskin via use-livecode
> Sent: Tuesday, October 06, 2020 2:01 PM
> To: [hidden email]
> Cc: Richard Gaskin
> Subject: Re: Canvas Limited to 32767
>
> Ralph DiMola wrote:
>
>   > I just ran head first into this. Could someone explain why other
> than  > moving from an int16 to an int32 this is such a challenge?
> This should  > have been addressed during the refactoring of the engine.
>
> Is this for the weird recommended mobile workaround of putting a text
> field into a group just to have it scroll, or something else?
>
> --
>    Richard Gaskin
>    Fourth World Systems
>    Software Design and Development for the Desktop, Mobile, and the Web
>    ____________________________________________________________________
>    [hidden email]                http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Canvas Limited to 32767

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Richard,

This design was done for one not to involve a lot of coding (App was free
development but we get a cut of each sale and it has worked out well for
us). Also there could be a reason to see the entire list but of course there
are other ways to do this as not to hit the limit. As far as device memory
is concerned I don't want to go to 2^31 but I am missing the cut by a couple
thousand pixels. If we had 2^31 it would be up to the developer to keep the
performance under control rather than apps breaking for 2 pixels over the
limit.

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf
Of Richard Gaskin via use-livecode
Sent: Tuesday, October 06, 2020 2:50 PM
To: [hidden email]
Cc: Richard Gaskin
Subject: Re: Canvas Limited to 32767

Glad it's not the funky mobile field workaround.  That's such a horrible
experience for developers that even the act of documenting it should have
been a red flag to go back and refine the field buffering for the few cases
where that put-it-in-a-group recommendation is actually needed.

In your case, you have a huuuuuuge canvas, with users expected to scroll a
region about 32 feet.  That's a lot of scrolling.

So in addition to the memory hit of buffering such a large region (32767
* 32767 * 4 + whatever other overhead comes into play with buffering), in
most layouts it would be a usability impairment to ask users to keep
scrolling that much.

So maybe the team could switch the address from 32 to 64, but it still leave
us with the question:

- Would a user have that much RAM?

- Would the user be able to use such a large canvas without acquiring
   RSI? ;)

I don't know your layout, but I do know you, and you're not the type to make
things hard for users, so I'm assuming there's something about this
uncommonly-large scrolling that fits well with the app's requirements.

But what we do know is no monitor can show it all, so the content is already
effectively paged into view as-needed.

Could the content paging be provided through some other UI? For example, if
those controls fit into logical groupings, might different sets of them be
placed into separate physical groups, perhaps accessed via tabs or a list?

If it's truly necessary to have one vast plane to hold everything, could you
handle paging internally while still providing the appearance of a
contiguous group, similar to how the DataGrid does it?

--
  Richard Gaskin
  Fourth World Systems



Ralph DiMola wrote:
 > Desktop and mobile. It's a scrolling group with many sub-groups each
 > with 1 or more fields. Sometimes the height of the main group > 32767.
 >
 > It's the result of a proximity search and in dense areas users are
 > getting hosed by this limit. Customer is screaming (but don't they
 > always).
 >
 > Ralph DiMola
 > IT Director


-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On
Behalf
Of Richard Gaskin via use-livecode

Ralph DiMola wrote:

 > I just ran head first into this. Could someone explain why other than
   > moving from an int16 to an int32 this is such a challenge? This
should  > have been addressed during the refactoring of the engine.

Is this for the weird recommended mobile workaround of putting a text
field into a group just to have it scroll, or something else?

--
   Richard Gaskin
   Fourth World Systems


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Canvas Limited to 32767

Paul Dupuis via use-livecode
I'm all for more freedom, but the RAM requirements make any practical
use of extended coordinates a less trivial problem.

Most programs handle this by paging. It may look like one contiguous
region on screen, but as you're scrolling it's dumping chunks that fall
out of view and rendering chunks coming into view, so the total viewable
space is well within practical memory limits.

The DataGrid shows one example of how to virtualize a scrollbar, using a
non-scrolling group with a separate scrollbar, and some clever coding to
make them work in sync.

With that, you can do like other programmers do, paging in an out the
parts you need when you need them. Only we get to do it in script.

If done in the engine it's the same algo, which AFAIK is very different
from how groups are buffered now.

So "just" changing from 32k to 64k isn't as easy as putting the word
"just" in front of it might make it seem. :)  It would require the
engine team to write a very different buffering algo, a lot of extra
work for a few edge cases not handled by what's in place now.

No doubt the team could do it, but I don't think it would be simple.

And given the low ROI relative to other priorities, if it went into the
work queue I wouldn't expect to see it for a long time.

Maybe Mark Waddingham can chime in if I'm overestimating the difficulty,
but I suspect scripting you own paging system with a virtualized
scrollbar is something you could do yourself in a fraction of the time
it would take to wait for it from the engine team.

--
  Richard Gaskin
  Fourth World Systems



Ralph DiMola wrote:

> Richard,
>
> This design was done for one not to involve a lot of coding (App was free
> development but we get a cut of each sale and it has worked out well for
> us). Also there could be a reason to see the entire list but of course there
> are other ways to do this as not to hit the limit. As far as device memory
> is concerned I don't want to go to 2^31 but I am missing the cut by a couple
> thousand pixels. If we had 2^31 it would be up to the developer to keep the
> performance under control rather than apps breaking for 2 pixels over the
> limit.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net
>
>
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf
> Of Richard Gaskin via use-livecode
> Sent: Tuesday, October 06, 2020 2:50 PM
> To: use-livecode at lists.runrev.com
> Cc: Richard Gaskin
> Subject: Re: Canvas Limited to 32767
>
> Glad it's not the funky mobile field workaround.  That's such a horrible
> experience for developers that even the act of documenting it should have
> been a red flag to go back and refine the field buffering for the few cases
> where that put-it-in-a-group recommendation is actually needed.
>
> In your case, you have a huuuuuuge canvas, with users expected to scroll a
> region about 32 feet.  That's a lot of scrolling.
>
> So in addition to the memory hit of buffering such a large region (32767
> * 32767 * 4 + whatever other overhead comes into play with buffering), in
> most layouts it would be a usability impairment to ask users to keep
> scrolling that much.
>
> So maybe the team could switch the address from 32 to 64, but it still leave
> us with the question:
>
> - Would a user have that much RAM?
>
> - Would the user be able to use such a large canvas without acquiring
>    RSI? ;)
>
> I don't know your layout, but I do know you, and you're not the type to make
> things hard for users, so I'm assuming there's something about this
> uncommonly-large scrolling that fits well with the app's requirements.
>
> But what we do know is no monitor can show it all, so the content is already
> effectively paged into view as-needed.
>
> Could the content paging be provided through some other UI? For example, if
> those controls fit into logical groupings, might different sets of them be
> placed into separate physical groups, perhaps accessed via tabs or a list?
>
> If it's truly necessary to have one vast plane to hold everything, could you
> handle paging internally while still providing the appearance of a
> contiguous group, similar to how the DataGrid does it?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
>
> Ralph DiMola wrote:
>  > Desktop and mobile. It's a scrolling group with many sub-groups each
>  > with 1 or more fields. Sometimes the height of the main group > 32767.
>  >
>  > It's the result of a proximity search and in dense areas users are
>  > getting hosed by this limit. Customer is screaming (but don't they
>  > always).
>  >
>  > Ralph DiMola
>  > IT Director
>
>
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On
> Behalf
> Of Richard Gaskin via use-livecode
>
> Ralph DiMola wrote:
>
>  > I just ran head first into this. Could someone explain why other than
>    > moving from an int16 to an int32 this is such a challenge? This
> should  > have been addressed during the refactoring of the engine.
>
> Is this for the weird recommended mobile workaround of putting a text
> field into a group just to have it scroll, or something else?
>
> --
>    Richard Gaskin
>    Fourth World Systems


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Canvas Limited to 32767

Paul Dupuis via use-livecode
We can just send a man to mars. Same deal. :-)

Bob S


On Oct 6, 2020, at 6:08 PM, Richard Gaskin via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

So "just" changing from 32k to 64k isn't as easy as putting the word "just" in front of it might make it seem. :)

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12