OpenXTalk Forums

OpenXTalkPaul wrote: ↑Thu Apr 11, 2024 2:00 pm You can also do this from a Github Web or GitDesktop (Graphical interfaces).

In theory, but I found that the gyp build tool won't build the mac source unless you download it via the cli git command. If you use the https or gitDesktop, is says that it's not a valid git repo and won't even get to the stage where git creates the mac xcodebuild files. So, short answer is looks like it has to come via the git clone command to work.

Edit: This post continues, here (because it became about compiling)

One observation I've made doing this, is that as the MacOS versions increase, the more demanding they are on the hardware. (The more sluggish they are).

I was just thinking about the speed differences you observed. For your 2010 Mac, presumably running 32-bit MacOS X 10.6

Then, on your later Mac, what system is installed on it? If you'd maxed this out with the highest MacOS it'd take, then it's going to be a lot slower - maybe slower than your 10.6 Mac?

So it could be interesting to hear from Windows users if they can remember a slowdown on LiveCode 7 and 8

Mic

I'll try and do a comparison between LCC 7, 8, 9.0, and 9.6.3 with the same computer (so it's a fair comparison), using your stack and see what the results are.

Edit: Here's a video with IDE load speed for comparison.

Top left: LCC 7.1.4
Top right: LCC 8.10
Bottom left: LCC 9.0.0
Bottom right: LCC 9.6.3

Results:
1st - LCC 7.1.4 (fastest load)
2nd - LCC 8.10
3rd - LCC 9.6.3
4th - LCC 9.0.0 (slowest load)

I actually found 9.0 to be the slower than 9.6.3. LCC 7.14 is blisteringly fast in comparison, but at the expense of no widgets (no widget section in tools palette), no data grids, and terrible font rendering.

This only shows the IDE load time, so I'll try and test with that stack next.

edit2: Dragged around the object you suggested. I'd rate them from least flickering as:

1st - LCC 9.0 (least flickering)
2nd - LCC 8.10
3rd - LCC 9.6.3
4th - LCC 7.14 (worst flickering)

(It's probably a very subjective thing) - but that's how I'd judge it.

micmac wrote: ↑Thu Apr 11, 2024 2:33 pm Paul you mentioned that there is libraries for sub pixel rendering (Skia)

Without sub pixel rendering in the ordinary stack we will never have good looking beziers. You can optimize the code as much as you will there will always be "knuckles" on the line. That's because of the lack of sub pixel rendering.

(if you answer this maybe it should be in a new thread)

Mic

Yes, the Skia library looks better and draws faster then the older Cairo (at least the way the engine uses it). LibSkia is same library as used by Chrome (which it was originally developed for) and other software for SVG rendering. Unlike 'classic controls' and buttons it can render nice smooth anti-aliased bezier curves with LibSkia.
It's really essential in my opinion to continue to support widgets since they're resolution independent too. Display pixelDensity are only going to get more dense in the future.

So surely the hardware matters very much. What you show on the video is not at all possible on my iMac 2017. The graphics move piece by piece.

Livecode 9.0 was released April 2018, so at that time the iMac was fast. But now its already 7 years old.

Maybe we should not measure the capability by such an old standard.


Its amazing what you put into it, Tom!

Mic

PS The iMac is still a wonderful machine. That's the beauty of Mac.
(Written on a beautiful MacBook Pro 2013)

I can run a very old version of LC on my G4 Mac Mini, and 963 on my 2015 iMac, but any speedcomparison will be worthless; and because of Mac's moving fences I cannot run them on the same machine.

micmac wrote: ↑Fri Apr 12, 2024 6:51 am Its amazing what you put into it, Tom!

I'm just an I.T. geek.

richmond62 wrote: ↑Fri Apr 12, 2024 6:55 am I can run a very old version of LC on my G4 Mac Mini, and 963 on my 2015 iMac, but any speedcomparison will be worthless; and because of Mac's moving fences I cannot run them on the same machine.

Yeah, exactly. Whereas on Windows and Linux - you are pretty much free to run LCC7 (and lower) all the way up to LCC9.7 on the same machine.

I've had to convert several old macs to Linux of some flavour, not because I preferred it - I mean, the older MacOS is nice to use (compared to the newer versions, where it feels more like fighting the OS) - but I had to 'linuxify' it just so that various printers were supported again, web browsers worked again etc

Planned obsolescence . . . ask King Camp Gillette:

Supposedly, years ago, some society woman, in the States, thanked Gillette for inventing the modern razor, to which he replied that he had not designed them for the convenience of men who wished to shave, but so that they would keep throwing them away and buying more.

As I have mentioned before: I have a family of Macs that would make both Goldilocks AND the 3 bears get seriously confused, just to run useful software; Oh, and to read CD and DVD discs.

On "any old Linux machine" I can run pretty well "any old version" of LC.

While climbing into bed with Apple 30-odd years ago (i.e. NOT having to cope with Windows 3) was quite sensible, the increasingly closed eco-system and the non-backwards-compatibility thing makes it less and less sensible if one wants to do slightly more than use your computer as combined entertainment centre and pastic bath-toy.

https://en.wikipedia.org/wiki/King_C._Gillette

Whoops: "Gillette is often erroneously credited with inventing the so-called razor and blades business model in which razors are sold cheaply to increase the market for blades."

tperry2x wrote: ↑Tue Apr 09, 2024 10:45 pm

xAction wrote: ↑Tue Apr 09, 2024 10:21 pm Remember the old Mac Extensions Manager? Maybe something like that is needed to turn off a bunch of stuff we don't use for day to day programming like LCB and datagrids.

Yes, I remember it well
This has definitely got my vote, and something I think is very much needed in 1.04 of OXT lite.

You will now be able to turn off a few more things as required from the preferences: (tested on two completely different machines)

What I do not understand is how excluding "dormant" files laying around in a folder somewhere can benefit perfomance?

Mic

micmac wrote: ↑Sun Apr 14, 2024 7:01 am What I do not understand is how excluding "dormant" files laying around in a folder somewhere can benefit perfomance?
Mic

The data grids aren't dormant. Even if you aren't using them, if you open up the "Application Browser" - and have all open stacks visible, you'll see that as default they are all actively loaded (even if not being used).
This hurts performance as they are still actively checking and receiving messages in the background:

Also, I just added this for Linux users which should help.

Edit, so it then occurred to me to test your stack again with this setting on:

Just to throw a spanner in the works (well, not really a spanner, but several things that spring to mind):

1. Screen speed does not always matter: it depends to a very large extent on what you are trying to do:

1.1. Where it might really matter in with regard to games and animations (c.f. several clunky offerings of mine).

2. Screen speed on desktop devices is one thing, while screen speed on mobile devices is another (mainly because the types of application one might be designing for mobile devices tend to be different to the devices one designs for desktop devices).

Why am I pointing out something that, after a moment's thought is screamingly obvious?

Just because I have seen companies and individuals get so obsessed about one particular thing in their business/life/whatever that they have neglected other things that may be equally important, and as a result ended up in the @#$%.

I personally see no harm in trying to improve performance of OXT lite wherever possible.
I'm not a company, so... timescale doesn't matter does it?

With mobile deployment, some phones can have greater performance than a desktop or laptop computer these days - however the limiting factor there will be that the mobile standalone targets are now 'stuck' at iOS 14 (circa 2020) and Android 10-'Q' (circa 2019) respectively.

They'll in theory remain that way without anyone updating the mobile build tools.

Preference "Disable Data Grid". Very nice. I've always thought modularizing for speed vs feature was a good idea. Suggest "Disable Data Grid (improve speed)" to inform users of its intent.

How would a DataGrid affect performance where the user hasn't chosen to use one?

What would be the implications of a stack where a DataGrid was used and then sharing that with someone who disabled DataGrid support?

TerryL wrote: ↑Wed Apr 17, 2024 7:41 pm Suggest "Disable Data Grid (improve speed)" to inform users of its intent.

That's a very good point, so I've just done this: I should add that when the datagrids are called upon, they are loaded as need be. (For example, when opening a dictionary stack - or anything with datagrids). But during normal use, when the datagrids are seldom used, they are now closed off - which stops lots of background messages polling in the engine's queue - not that you can see them from the message watcher - they are internal engine calls that go back-and-forwards if the stacks are in memory. A short way of saying that would have been they are loaded as needed, and deactivated as required. (Dynamically).

It's not a vast difference, granted - but all these little things being loaded into memory definitely adds up. Especially if they are set to be sent internal messages "__DataGrid[*]" when they aren't being actively used in the IDE or by backscripts. It also saves a few MB of memory when they aren't active. Again, not a lot - but every little helps on low end machines.

That's my focus, as on a fast system - you'd not see a difference. But, running OXT Lite on a low-end system, you definitely would be looking for any speed increases possible in the IDE. The more stuff going on in the background, the more sluggish the IDE will be.

Why bother? Well, if the IDE is nice and responsive, this won't be a negative point against it during general use - especially for people who can't afford up-to-date computers.

But ultimately, this is why it's a preference. If you don't like it, leave the feature turned off. (It's off as default anyway, so doesn't try to do anything with the datagrids as default).