Rendering performance on Linux

[LCMark]

@FourthWorld - that would, indeed, be me

[monte]

and it was such a cunning disguise

[ricochet1k]

@runrevmark: I have added a new pull request for the faster graphics changes.

mwieder said that he didn't notice the artifacts I was seeing, but I've been seeing them since the 6.0.0 official release, not compiled by me. In any case, that commit should fix them.

[mwieder]

I also don't see artifacts after implementing Matt's fix.
Seems like an extra draw step that wasn't necessary. Or may have been at one time.

[LCMark]

I spent some time staring at the code for this yesterday and couldn't see why it was necessary (the copy to/from the alpha mask) in general...

The only thing I can think of is that it is related to image editing operations - in this case, when the context is created it is 'given' the alpha mask of the image to update (so that where pixels are drawn full opacity is recorded). However, this wouldn't need to by re-synched after every operation, just when the context is deleted.

Now, I couldn't recreate any artifacts with the image editing tools operating on an alpha-blended image with that code commented out. I can't decide whether to be slightly alarmed about this or not - in theory without that code the image's (external) alpha channel is not being updated so it should be out-of-sync with what is expected...

[ricochet1k]

I wasn't able to figure out what the mask is even used for other than messing with alpha stuff. I almost tried removing all the mask code, but I wasn't brave enough. There are some things, like mergealpha IIRC, that just lock and immediately unlock without doing anything else, which should be a noop, right? Lots of stuff doesn't make sense.

[LCMark]

From memory there are two masks floating around - a 1-bit mask to record the pixels touched by the X11 drawing calls; and an 8-bit alpha mask if the context is created with one (or given an external one).

The 1-bit mask is to ensure after an X11 call, the top (alpha) byte in the actual pixel array is correct - I'm not sure X11 guarantees anything regarding the integrity of the top (alpha) byte after its touched a pixmap (GDI on Windows certainly doesn't). [ flush_mask() does this - it goes through and puts 0xff in the top byte of any pixels touched ].

As I said, it isn't at all clear looking at the code why the alpha-mask was being continually synched - it shouldn't need to be... Just merged in when the context is created, and pulled out at when the context is deleted at the end.

[ricochet1k]

One area I've noticed is particularly slow is when we have fields with large amounts of styled text. I haven't yet looked at the source code, but I suspect that, in addition to the broader areas you're looking into, there may be many opportunities to enhance LiveCode's use of the Pango APIs.

In messing with GLX2's source code, I've found that switching between tabs in the script editor and editing text when there are several thousand lines of code open is horrendously slow (roughly one second per keystroke!). I'll probably profile this particular use case in the next few days, although given what I've heard from runrevmark about the state of the text rendering/storage code, I'm not terribly hopeful.

[mwieder]

You're no doubt looking at the main stack script in GLX2, which is some 11000 lines of code. Yes, the script editor is very slow in dealing with that amount of text. One second per keystroke seems about right. Not all of it is rendering, though, because GLX2 itself is somewhat faster at dealing with code editing. Still, I've got it running about as fast as I can and it's still much slower than editing text on other platforms.

[LCMark]

@ricochet1k: I suspect when you profile you'll find that the time sink is the (pango) layout code in MCNewFontlist::ctxt_drawtext() - it might be that a simple (hash-table style) cache of the PangoLayoutLines against the input string and font might speed things up there quite significantly. (Which would be an easier job at the moment than trying to make the field cache such data on a per-paragraph basis!)

[ricochet1k]

Running under the profiler is quite hilariously slow. I typed out 3 long-ish lines of script inside the 11000 lines of the GLX2 stack, and several minutes later it's only halfway through the first one.

At the top of the performance issue is inside MCParagraph::layout() at 61% of the time, all the way down to the deepest level in pango_layout_get_pixel_extents at 55% of the time. It seems like it should be fairly easy to cache the text size of each paragraph, invalidating it when it's dirty. I'm going to start reading the code now.

[ricochet1k]

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 selectively invalidate the paragraphs/lines/blocks that were affected by an edit?

I could add a context specific hashtable for the width of a chunk of text, but I think making blocks/paragraphs better cache their computed values will be much more effective.

[mwieder]

Oooo... nice find....

[malte]

Indeed! Thumbs up!!!

[LCMark]

@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 so blocks only recalc when adjusted that would most likely obviate the need for a 'textwidth' cache.

Btw, it's great to get another set of eyes on stuff like this - I've done a lot of work in the field over the years and it's easy to get entrenched and develop 'code-blindness' with such things