https://github.com/runrev/livecode/pull/158
Sorry it took so long. I kinda forgot about LiveCode for a while.
Search found 39 matches
- Fri Aug 30, 2013 2:58 am
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
- Thu May 23, 2013 6:56 pm
- Forum: Engine Contributors
- Topic: filter enhancements
- Replies: 100
- Views: 68778
Re: filter enhancements
Regular expressions can be made to match negatives, but the results can be painful. What's the opposite of /abc[def]+ghi/ for instance? A not option sounds like a good idea to me. Are the regexs going to be a string or a new pattern token like Perl/Javascript/etc.? String patterns will be very annoy...
- Fri May 10, 2013 5:08 am
- Forum: Engine Contributors
- Topic: Strange IDE bug
- Replies: 2
- Views: 3310
Strange IDE bug
Ever since I found out about gRevDevelopment, I've been playing with various things with it on to see what happens. I noticed that the Project Browser is really slow when scrolling, so I decided to try to figure out why by writing a simple script that looks for all the disclosure buttons and expands...
- Thu May 09, 2013 6:11 pm
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
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 :P I wish I had known about it back when I was writing my own toy game engine. Hmmm - this might be because b...
- Thu May 09, 2013 6:22 am
- Forum: Games
- Topic: Protect Earth !
- Replies: 5
- Views: 5793
Re: Protect Earth !
@splash21: I've been working on fixing various performance issues on the Linux version of the engine, and I have fixed one major source of slowness with rendering. I'm pretty sure I also found the cause of the same rendering glitches you show in the video, but I'll have to try your stack out to be s...
- Thu May 09, 2013 6:05 am
- Forum: Engine Contributors
- Topic: the dreaded 64-bit compile
- Replies: 122
- Views: 69267
Re: the dreaded 64-bit compile
I see. Odd that that wasn't tested better before the release. Is there an internal RunRev test suite?
- Thu May 09, 2013 6:02 am
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
Turns out all the code to cache block widths was already there, but for some reason noflow was resetting them all, and I can't determine a reason why. https://github.com/ricochet1k/livecode/ ... c86a7efd8b
- Thu May 09, 2013 2:46 am
- Forum: Engine Contributors
- Topic: the dreaded 64-bit compile
- Replies: 122
- Views: 69267
Re: the dreaded 64-bit compile
I get that, but there are general fixes in that branch, not all of it is 64-bit only. Plus, it's good to test that 32-bit builds still work with it.
That and runrevmark was specifically asking about the new 64-bit code, since you are one of the developers who has worked on it in the past.
That and runrevmark was specifically asking about the new 64-bit code, since you are one of the developers who has worked on it in the past.
- Thu May 09, 2013 2:10 am
- Forum: Engine Contributors
- Topic: the dreaded 64-bit compile
- Replies: 122
- Views: 69267
Re: the dreaded 64-bit compile
You need this commit: https://github.com/runrevmark/livecode/ ... 0a62e1dc6f
That is not on either the master or develop branch yet. Use runrevmark's feature-linux_x64_2 branch with the feature-linux_x64 branch for all the submodules.
That is not on either the master or develop branch yet. Use runrevmark's feature-linux_x64_2 branch with the feature-linux_x64 branch for all the submodules.
- Wed May 08, 2013 11:41 pm
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
Having Linux performance be fast is especially important when it comes to computers like the Raspberry Pi (I have one, so I may end up playing with this at some point too) because they are less powerful machines, and need all the speed the engine can give. Which brings up an interesting point: does ...
- Wed May 08, 2013 5:08 pm
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
Well, that was surprisingly easy. Holding down backspace is still pretty slow, but performance is a lot better than before. Changes here: https://github.com/ricochet1k/livecode/ ... 38b9d06a04
- Wed May 08, 2013 4:39 pm
- Forum: Engine Contributors
- Topic: the dreaded 64-bit compile
- Replies: 122
- Views: 69267
Re: the dreaded 64-bit compile
I still had to make a few tweaks, such as adding #include <glib.h> to lnxspec.cpp and converting tabs to spaces in archive.linux.makefile and environment.linux.makefile (make doesn't like tabs used for indentation, only for rules). I thought I had to do something about the system libcrypto conflicti...
- Wed May 08, 2013 4:01 pm
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
PS_LINES_NOT_SYNCHED seems to almost be the dirty flag I want, but it doesn't seem to be used everywhere it seems like it should. Do you know why lines are deleted and recreated in noflow()? That seems to be the one place where doing that should be unnecessary. Maybe only if state & PS_LINES_NOT_SYN...
- Wed May 08, 2013 3:09 pm
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
@ricochet1k: Good find! I'd actually forgotten the field was 'dumb' enough to do that! As for why it does it, then lack of time to optimise appropriately is perhaps all I can say. Certainly if you can make it so paragraphs recalculate when changed that would make a big difference - then making it s...
- Wed May 08, 2013 1:41 am
- Forum: Engine Contributors
- Topic: Rendering performance on Linux
- Replies: 60
- Views: 37862
Re: Rendering performance on Linux
Heh, no wonder drawing text is slow. It recomputes THE ENTIRE FIELD any time ANYTHING changes! Is there any reason why every single Paragraph has its layout recomputed, every Line is deleted and recreated, and every Block is reset, even when most of them didn't change? How hard can it really be to s...