LiveCode Forums.

@ricochet1k:

Pango actually uses HarfBuzz on Linux for "complex text rendering" (http://www.pango.org), but since HarfBuzz is being used by GNOME, Firefox, Chrome OS, and Chrome, it's probably a safe bet I wish I had known about it back when I was writing my own toy game engine.

I must confess it has been a while since I last looked at this aspect of things on Linux... If harfbuzz is used by all of those it must be pretty complete by now - we'll have to do some digging and research

I have hit a bug with layout() not being called when it should have been causing an infinite loop, but I suspect it's because clearzeros isn't setting the dirty flag. Debugging this could be very difficult. It would be very nice to have some kind of code proving engine with constraints saying something like "whenever this changes, this needs to be called before this is called" and have it tell me the sequence of events when something breaks...

Hehe - oh that would be nice. I know the world of code-proving and such has moved on substantially in the last few years (particularly as efficient and freely available implementations of the boolean satisfiability algorithm now exist), however I'm not sure quite what the frontier of such research has produced as yet in terms of production-quality tools (I've not had the time in recent years to keep up with it). Not entirely related, but LLVM has a sub-project for 'symbolic execution' which essentially runs a program abstractly and attempts to tell you all the ways it might break... Unfortunately, I think the engine might be a bit big for that at present (well, unless someone wants to gift us a suitably sized super-computer)

By the way, do you want to send a pull-request for the paragraph optimization you made? The commit you posted looks pretty solid, we could test it out on the 'develop' branch for the next major release if you want... See if anyone manages to break it.

runrevmark wrote:@ricochet1k:
By the way, do you want to send a pull-request for the paragraph optimization you made? The commit you posted looks pretty solid, we could test it out on the 'develop' branch for the next major release if you want... See if anyone manages to break it.

Was that pull request submitted?

I was working in v6.1.1rc3 last night on Ubuntu and the script editor still seems slow (at times almost prohibitively so).

Also: do we have an estimated timeline for the implementation of Skia?

There's no pull request for the changes, but I built an engine from Matt's mymaster branch, and I can attest to the fact that it's (subjectively - I didn't try to benchmark it) an order of magnitude faster.

mwieder wrote:There's no pull request for the changes, but I built an engine from Matt's mymaster branch, and I can attest to the fact that it's (subjectively - I didn't try to benchmark it) an order of magnitude faster.

That has me drooling. What are the odds this can be in v6.1.1GM?

Practically nil. The changes have to ferment a bit in the develop branch after the pull requests have been accepted. Then at runrevmark's whim they may be pulled into the master branch for release builds. Now that 6.1 is at release candidate stage there's slim chance of anything else making it into the release aside from some bug fixes in the rc builds.

Dang. But since the newsletter said they'd have resolution independence done soon and it's not in 6.1.1, maybe we won't have to wait long for v6.1.2 or 6.2 or whatever they'll name it.

Man, an order of magnitude....

https://github.com/runrev/livecode/pull/158

Sorry it took so long. I kinda forgot about LiveCode for a while.

@ricochet1k: I'm glad you remembered about LiveCode

As I said in the pull-request, the new graphics rework has caused Mac to have a similar performance problem with measuring text as Linux (as everything now has to be passed through Unicode measurement routines). The field layout optimization when finished (Matt's been working a bit on a couple of issues I've noticed, and I think we're almost there) is going to be a huge boon to all platforms.

We've also mitigated the problem by adding a measurement cache in the graphics library, so rather than measure strings again and again it will fetch them from a cache if it can. This still needs a bit of fine-tuning but with just the cache performance on Mac seems to be back to nearly where it was when most of the text was going through the ancient QuickDraw code - the field optimizations will improve this even further (after all, the fastest code is code which is never called ).

Did this pull request wind up in the v6.1.1 release? Maybe it's just my optimistic imagination, but things seem a little perkier with fields containing a lot of text in this version.

@FourthWorld: I suspect any small improvement in performance in 6.1.1 is due to my optimization to word-wrap computations - previously it was repeatedly measuring text at each character boundary when laying out, rather than just at potential word-break positions.

@RunRevMark: Nicely done - thanks. Is there an off-the-cuff estimate you could give for the other optimizations to be completed?

@FourthWorld: The measuring cache is in 6.5-dp-1 - I'm hoping to look at and integrate the layout optimizations @ricochet1k has done this week (also into 6.5).

Okay, so a little optimistic with my last post...

Building on @richochet1k's work, @runrevfraser added the extra logic to make sure things always layout when needed (particularly resize and field-level props) and things seem a great deal speedier now. We've also done some further optimization on line fitting, which has further improved performance. All this work will be in 6.5-dp-2.

Where is the like button for that?

Do you have an estimate on the arrival of DP2?

Cheers,

Malte

@malte: As soon as we can - we're just ironing out a few last issues with it at the moment...