FileMaker 15: Portal In-Line Progress Bar

FileMaker 15 users are no longer blocked from interacting with a layout due to a portal taking a long time to load. The new portal in-line progress bar feature (a.k.a. threaded portals) offloads the task of loading “expensive” portals onto separate worker threads, so that the main thread can finish more quickly and return control back to the user.

---

Video Transcript:

My name is Mislav Kos. Today, I’m going to tell you about the Portal In-Line Progress Bar feature, new with FileMaker 15.

Here we have a layout based on a System Table with just one record. We see a portal showing contacts. The contact table has one million records. The relationship is set up so that whatever number I enter the “Show this many contact records” field is how many contact records we’ll see in the portal.

For example, if I enter in 2, we’ll see two contacts. If enter in 5, we’ll see five of them. Now, if I enter in a really big number, for example, one million, then it’s going to take a while for all those records to be downloaded and for the portal to be displayed completely.

Historically, FileMaker clients like Pro and Go have operated on a single thread. FileMaker Pro and Go render a layout, gather all the data including for any portals that are on the layout, perform whatever calculations are necessary, and draw the layout all on a single thread.

Let’s take a look at this behavior using an older client. I have FileMaker Pro 13 opened here. It would work the same way with FileMaker 14 as well. I’m going to type in 1,000,000 in the “Show this many contact records” field. We get this nice beach ball here letting us know that the work is in progress. During this time, we are locked out of the layout. We can’t interact with it at all.

Let’s see how this works with FileMaker 15. After a half second or so, we see a progress bar. FileMaker starts rendering the portal, and if it takes longer than a full second or so, it transfers that work onto a worker thread; the main thread continues on with the rest of the layout. In so doing, FileMaker returns control to the user much more quickly.

If we do this again, you can see that I am able to enter data inside the fields and tab through the fields on the layout while the portal is still loading. Note that for trivial portals (portals that take less than a half a second or so to load), all of the work rendering it will remain on the main thread.

A couple of things to note at this point. The overall time to render the full layout will not be reduced. This multi-threading is merely separating the task of drawing out a portal onto a separate thread so that users can interact with the layout more quickly while task completes.

The tab order is set up so that when I tab out of field A, I should go to the portal fields next. And after those, I end up in Field C to the right here. But, note that if the portal is still loading, the portal fields will be skipped; I will tab directly into the field following it.

Also, if I clear the key field midway through while the portal is still loading, that action will implicitly cancel the execution of the portal worker thread. And if fact, the portal thread will be implicitly canceled whenever the portal no longer needs to be displayed. This can be because we switched to a different record or we switched to another layout. Maybe we scrolled records shown in a list view so that a portal that was previously visible is no longer on screen. Or, because we switched away from browse mode or maybe we closed the current window.

However, if you do cancel a portal thread and will need to draw that portal again later, all of that work of drawing that portal will need to start from the beginning.

Finally, note that I have this file hosted on FileMaker server 14. We are able to see the portal in-line progress bar because I’m using a version 15 client. The server version doesn’t matter.

This version is the same as the one before except that the portal is really narrow. If a portal is too small to draw the progress indicator circle, then it will not be shown. You can see that the portal is still being loaded on a separate thread because the portal data is not visible yet. I’m still able to interact with the layout. Now that the worker thread has finished, we can see the portal data.

On this layout, I have two portals, each one pulling data from a different table. If I am displaying enough data so that it takes the portals a while to display, each portal will get its own worker thread and we will see a progress bar in each one. There is no artificial limit to how many worker threads can be spawned at a single time. But, keep in mind that each additional thread will have the effect of slowing down the existing threads because each thread does use up CPU time.

As I said earlier, FileMaker Pro and Go clients have historically functioned on a single thread. But, this portal threading isn’t the first instance of multi-threaded operation. I’m going to switch back to FileMaker Pro 13 here and go to a layout that shows a container field that holds a PDF file.

I have this container field optimized to show images. Pay attention to the container field as I resize the window, and you’ll see a progress bar circle. The PDF that is stored in this container field is shown using an image that is based on the first page of that PDF.

As I resize the window, the field is also resized. FileMaker then needs to create a new version of that image to conform to the new size. This work used to be done on the server, but starting in version 13, the image can be generated on the client as well. When it happens that way, it is done on a separate thread. This generally happens very quickly. The effect is less dramatic, and as users, we tend not to notice it. It’s just sort of something that happens in the background. Keep your eyes on the container field as I scroll through the rest of the records. For a split second, you will see the progress indicator circle shown in the container field before the image itself is shown.

We’re back in FileMaker Pro 15 now, and on the layout, it shows an unstored calculation field which relies on all of the data in the portal to be determined before it can evaluate. This unstored calculation counts the number of records shown in the portal. Let’s take a look at what happens when we set our field to show all one million records. And, no more multi-threading. The entire operation is back on a single thread. The user is forced to wait for it to complete before being able to interact with the layout.

Here’s another way that will force a layout to be rendered entirely on a single thread. This script will set the field to 1,000,000, just as we have been doing by hand. The next step will count the number of records. If I run this script, we see I am not able to interact with the layout. And we see the same old modal dial-up window as we use to see in prior versions of FileMaker. When the first step in the script is run, FileMaker is smart enough to know that there is dependency later on in the script for the entire portal to be loaded. And so, the entire operation takes place on a single thread.

Here is another example of this behavior. In this case, the script goes to the ID field in the portal. As a result, we have to wait.

There is one other consequence of this multi-threaded behavior to keep in mind. There are several useful layout tricks relying on the calculation engine being available directly through the layout. For example, the visibility hide condition, the tooltip calculation, conditional formatting, and so on.

On this layout, I have an object placed all the way up in the upper left corner, arranged at the back of the z-axis object stack. I have another object placed in the bottom right corner pushed to the front of the z-stack. The first object records the current timestamp using a let statement and a global variable. The second object does the same thing, subtracts the two timestamps, and stores the result in a global variable. This way, I can see how long it takes for the layout to load.

Switching back to 15 now, this trick will no longer work reliably because the main thread might finish before the worker thread does. Put more generally, be careful about setting global variables in any calculation that is accessible throughout the layout. However, setting global variables inside of a script will still be okay, because scripts are still fully single threaded.

I hope this was a useful introduction to the new portal in-line progress bar feature. Please check out our other videos at Soliant TV, and thank you for watching!