Rendering performance on Linux

[ricochet1k]

I was tinkering with a little script to generate a grid of rectangles to fill a card, and I was surprised by how slow rendering of those graphics is. At 10x10 and filling the card, my naive solution (no lock screen/messages) gets exponentially slower with each new rectangle added, taking about 2 seconds per square at about 75% complete. A little tinkering with Callgrind shows that 36.7% of the time is being spent in surface_merge_with_alpha_non_pre and another 36.7% being spent in surface_extract_alpha. Now, I know that doing all that without locking the screen/messages is stupid, but lets ignore that for now.

Does this happen on builds other than the Linux 64-bit build I've been tinkering with? Windows? Mac?

Is there a reason that every graphic is being redrawn any time a new one is added? Is there a way to stop that from happening at the engine level? Or at the very least, a way to avoid that alpha copy on every lock/unlock?

I haven't done enough testing yet to be sure, but I suspect the X11 drawing API isn't terribly fast. It is also way outdated, which will prevent easily supporting a different display server in the future, such as Wayland. Would it be worth the effort then to switch to a different drawing library, such as Cairo?


Also, I haven't tried to figure out why yet, but is there an obvious reason why turning on acceleratedRendering on Linux makes rendering ~10 times slower?

[malte]

Hi ricochet1k,

I am afraid I know nothing about the engine code. Just wanted to let you know that I will follow this thread with huge interest, as I too think the rendering performance under Linux leaves quite a bit to be desired. Thanks for looking into this.

Best,

Malte

[mwieder]

Matt-

Yes, rendering under linux has been a problem for some time now, although it seems you're getting some pretty extreme results. Some have found earlier that updating graphic drivers (esp nvidia) makes a huge difference in rendering time. I haven't looked into this section of the engine code yet, but I think you're onto something with the X11 graphics stuff. I'm sure that part of the engine code hasn't been tinkered with in a *long* time.

I wasn't aware that acceleratedRendering did anything in the desktop engine - I thought it was just for mobile. Anyway, if you search the listserv archives there's some discussion about why and when to turn it on and off. I didn't need it at the time, so I don't remember the details, but if you can't find the references I'll search and dig them up for you.

[ricochet1k]

Report on what I've found so far:

Commenting out the surface_merge_* functions in lock_layer and unlock_layer of lnxcontext.cpp greatly speeds up LiveCode. So far the only negative effect I've been able to find is that the "import snapshot" command doesn't have the correct alpha/mask values. It does, however, make another bug with "import snapshot" a little more obvious: The buffer isn't being cleared before the control is drawn on it, so any pixels that aren't fully opaque, such as antialiased pixels or drop shadows, have odd looking garbage in them. Now the mask isn't being updated at all, showing all of the extra crap, not just the area the control overlaps with.

I haven't yet figured out why the buffer isn't being cleared. Any suggestions are welcome.

[mwieder]

Cool. I commented out the surface_merge_with_alpha_non_pre call in lock_layer and the surface_extract_alpha call in unlock_layer as a test, and graphics do seem faster.
But I'm not seeing alpha artifacts on importing snapshots - the drop shadows are crisp, and so far I don't see any problems with this. Do you have a sample stack that would show the problem?

[ricochet1k]

The effects are the most obvious if you create a non-opaque graphic and import a snapshot of it. I was seeing all kinds of graphical artifacts. Parts of the file menu I had just opened, etc.

But I just found the source of the bug: Newly created layers were not being cleared at all. There was code preventing clearing if it was a "base pixmap" because it might have other images relying on it. This may need to be fixed in a different way, but I'm honestly not sure how to cause the engine to create a dependent image and clear the original.

My fix is here: https ://github. com/ricochet1k/livecode/commit/c7cbb1f1f5a877128fb7ad5a1ee6eccd1639c024


Why do I not have permission to post links?

[mwieder]

You have to have made a certain number of posts to the forum before you have enough reputation to post links. Keeps the spam down to a minimum. I think it's around 15 posts or so.

[mwieder]

Matt- I wasn't seeing artifacts before, even with importing sparse alpha masks. Don't know why. But I pulled your commit and it seems to work fine. And graphics are indeed faster. Very nice.

[FourthWorld]

Matt and Mark, thank you for diving into this. The more I've learned about Linux the more I've come to understand that when we consider the full scope of modern computing, from servers to embedded systems to mobile, it's become the de facto standard of computing, and LiveCode needs to improve on that platform.

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.

I'll be watching this thread with keen interest, and look forward in the coming weeks to helping out by reading the code and the relevant APIs, and seeing if I can lend a hand in bringing the two together more gracefully.

In the meantime, I very much appreciate you two and others who are doing this work. Linux rocks, LiveCode rocks, and I'd love to see a world in which they can rock together as powerfully as I know they can.

[ricochet1k]

If you can send me an example stack with really poor performance with the styled text, I'll look into benchmarking and investigating. I'm afraid that I got lucky with the fix I did find, so it's not likely that I'll find something to fix, but I will try.

[malte]

I do have a stack (very very complex though and requires a postgreSQL database to be present) that performs really poor under Linux. In fact performance is that poor, that it is barely usable.

If that would help (and you would be willing to set up a postgreSQL DB for it) I could make that one available.

Cheers,

Malte

[LCMark]

There are a couple of issues underlying the rendering performance on Linux.

The main one is that the Linux drawing code still uses X11 calls wherever it can which occur server-side; however, X11 isn't very good at alpha-blending stuff and so this has to occur client-side. This produces a fair amount of overhead - even when using shared memory segments (which can occur in some cases) as data has to be moved back and forth between app and XServer. We're actually working on replacing the per-platform MCContext classes completely with a platform-independent rendering library (Skia, as it happens) and this should resolve a significant amount of the performance issues on Linux as all rendering will happen client-side, with the server only becoming involved to 'blit' the result to the window/screen. I can't give you an ETA on this work yet, but it's basically one of our top priorities (its a key piece of resolution-independence) and is happening alongside the syntax/refactoring project. However, if you do profile the code and find a few changes that can speed things up now (with no loss of functionality) then we'd certainly be more than happy to see if we can integrate them in the interim period.

The other issue with Linux 'rendering performance' is (as Richard points out) with text. This is also something we hope to sort out as part of the graphics rendering overhaul, but a good deal of it comes from how the field internally stores, processes and lays out text. The latter is a bit of a mine-field and really needs a complete overhaul, but again if you see any room for optimization with how it is now just let us know

[ricochet1k]

Ooh, Skia looks cool. Does that mean we will be able to apply rotation/scaling/opacity/etc. to button sprites?

As for the changes I did already, do they cause a loss of functionality? I haven't been able to find any case where something does not look correct.

malte: I've never used Postgres before, but it shouldn't be difficult for me to install it and set up a database. Have you tested your stack with my graphics changes?

[LCMark]

@ricochet1k : Yes, we do plan to improve image transformation options since Skia does general 2d affine transformation... Which works quite well with the changes in 6.0 which mean you can effectively do away with using buttons with icons - image data of referenced images (those with filename) are shared based on absolute filename so you can have as many image objects referencing the same image and have them only use one copy of the data.

In regards to the changes, I missed the bit where you said you'd fixed the issue with snapshot... If you send a pull-request for the changes you've made we'll take a look and see if we can integrate for the next non-maintenance version.

[FourthWorld]

Is "runrevmark" Mark Waddingham?