1 2 3 Previous Next 30 Replies Latest reply on May 18, 2012 11:42 PM by NickLightbody

    How to speed up FM12 layouts for faster screen redraw ?


      Many people here complain about FileMaker 12 being slow. And yes, it is slow, at least regarding screen redraw of complex forms, large and long lists and tables.


      But it is no wonder, since the new css based drawing engine has much more to do with interpreting the layout and rendering it. Instead of one type of radio button and checkbox, one type of rollbox and popup icon, there are now endless possibilities for these UI gadgets plus millions of possible color gradients, all combinations of thinkable rounded corners, textured backgrounds and hover effects. All this has to be computed.


      So of course with complex layouts FileMaker 12 will be slower than former versions, which showed us stone age graphics on the screen. There may be some room for optimization in the code on FileMaker´s side, but I guess and I am sure that FMP12 will never be as fast in screen redraw as older version were.


      So a new question for us developers will be, how to speed up our layouts. Of course an empty layout will be the fastest, but that is no real solution. For finding a solution we would have to know which kind of elements are slow or slower than others. I have collected some questions, which - perhaps - can only be answered by FileMaker and hopefully will be answered:


      - Is there a sense in rebuilding a file from scratch in fmp12 format regarding the screen redraw speed or can a converted file be as fast as an original file ?

      - how does conditional formatting impact the speed ? Are hover effects having the same impact ?

      - which elements are faster ? bitmap graphics with a gradiant or a native gradiant ?

      - what is better: embedding bitmap icons on every layout or taking them from a centralized table ?

      - are texture and gradiant backgrounds much slower than only one color fills ?

      - Do special fonts increase or decrease the speed ?

      - how about tabs ? Are hidden tabs and elements on them of any importance for the screen redraw speed ? Does FileMaker only calculate visable elements ?

      - Up to how many lines can a portal row be shown without having a speed effect ?

      - How does the kind of relation speed up or slow down a portal ? How much slower are filtered portal rows ?


      Knowing all that would help us developers to decide, what elements could be skipped completely or moved to helper layouts for increasing the speed redraw of our main screens. Thanks in advance.

        • 1. Re: How to speed up FM12 layouts for faster screen redraw ?

          The only responsible way is to bitch FMI a lot, make everybody who's considering FMP aware that 12 is a slow dog that sould be skipped, and boycott it.


          Filemaker 12 is not 3D ray-tracing the UI, it's nothing that fancy. Any webbrowsers out there render webpage much much more complex than the most complex FMP layout in a fraction of second.


          We're in 2012, there's no excuse for that slowness. Except the fact that FMI managment bets it can shove it to us making big bucks without serious complain. Let's show them how wrong this bet is.

          • 2. Re: How to speed up FM12 layouts for faster screen redraw ?
            Stephen Huston

            I will offer one bit of info that has been hashed out regarding your question "- how about tabs ? Are hidden tabs and elements on them of any importance for the screen redraw speed ? Does FileMaker only calculate visable elements ?"


            Tab-based info can slow screen refreshes and network peformance in general even if non-selected tabs have portals or other forms of related data. All TOs referenced anywhere on a layout have to be cached across the network, even if not visible. The only exceptions are unstored calcs and containers which are not actually placed on the layout or used by fields which are placed.


            So having 3 tabs with 3 portals to different tables will force all 3 tables to cache across the netwrk even if only one is visible. This is NOT what we used to be told, but it is what was discovered to be happening in very careful testing as reported last year at DevCon.


            So simplify

            1 of 1 people found this helpful
            • 3. Re: How to speed up FM12 layouts for faster screen redraw ?

              I have to agree with fmlvince here. Sure learning how to make things works faster in 12 could be useful but to imply that we now all have re-engineer many of our layouts just to get them to perform well in 12 is ridiculous. Who is going to pay for that? Who has time for that? As I have said before in other discussion there is no rush to go to 12 and you can downgrade to 11 for years which still has lots of life left in it. This release seems to have more to do with trying to sell more iPads and iOS devices then actually advancing the platform and delivering useful features that people actually want. I really don't see myself ever going to 12 (unless some patch miracualosly fixes it) and hope by 13 they have the new CSS engine figured out and have added some features that will be of real benefit to my customers. Time will tell...

              • 4. Re: How to speed up FM12 layouts for faster screen redraw ?

                Thinking about speed optimization we had the following ideas:


                1. Layouts with hundreds of fields, dozens of tabs and x conditional formatted fields are slow in FMP12 - ok. But are such layouts a really good idea in the sense of usability ? I doubt that. No user can overview such a layout and in many ways it will be good for nothing. So less is more and detailed information should be put to detail layouts. By that you clean up the main layout and get the speed you wish.
                2. Instead of using x tabs one should think of detail layouts that popup in modal windows on user´s demand. This will tremendously speed up the main layout, for the user the information is still only one click away and the effort to realize that technique isn´t really big. One script to open the window and a new layout to which you copy the content of the tab. It doesn´t even change the logic of your user interface that much, since the button for opening the detail window could be placed where the tab was.
                3. Same applies to long and large lists - instead of placing so many fields directly in the list itself give the user a "More ..." link that opens up a detailed information window for the chosen record.
                4. Conditional formatting slows down all layouts, since the conditions could be various and obviously are calculated four times (one time for each condition normal, hover, clicked etc.). We guess, the following technique will be much faster. Place $$variables on your layouts and calculate these by on record load script triggers. In the calculation you can not only change the look with text formatting commands - as you can with conditional formatting - but you can also change the content of the element even to nothing or something completely different. This technique is much more flexible than conditional formatting and faster.


                Any ideas ? Can you confirm our ideas ?

                • 5. Re: How to speed up FM12 layouts for faster screen redraw ?

                  Hi Intex, your solution for conditional formatting is very interesting, can you please give me more detail?


                  thank you so much.

                  • 6. Re: How to speed up FM12 layouts for faster screen redraw ?



                    These are all work arounds.  I guess it is the current reality, but to have to remove existing functionality based on RECENT features is really ludicrous to most people.  20" screens are common.  People want to see their data.  Pop up windows are annoying and don't really fit into the "browser" centric models people are getting used to.  In addition, there is a certain amount of overhead in opening and closing new windows all the time.  $$variables are OK for display objects, but still have some significant limitations.  I do a great deal of conditional formatting on ENTRY fields, and again, this is a relatively new feature.  To have to undue a bunch of new work performed to take advantage of this feature is infuriating. 


                    These are all good tricks to work around the problem in the short term, especially for new work, but ultimately, these performance issues are something that Filemaker can, should and will address.  If we can have 3D games with almost unstopped random action performing at 30fps or better, we should be able to have compartively simple data screens refresh at an acceptable speed with tabs and conditional formatting in place. 

                    • 7. Re: How to speed up FM12 layouts for faster screen redraw ?

                      For example if you have a status "Paid, due, etc". you can show that on your screen using conditional formatting in green, orange and red. Or - and this would be the alternative - you could calculate a variable $$status in a script not only changing the color but also changing the text. You put the variable on your layout and let a on record load trigger start your calculation script to have the variable updated.

                      • 8. Re: How to speed up FM12 layouts for faster screen redraw ?

                        First, I would hope for more speed too. But they worked for 24 months or so on what we got now. I would be very astonished if we get a real fast racing car out of this truck in the next three months.


                        Second, of course there are 20inch screens and much larger, but there are 4inch, 7inch and 9inch displays too. Working with a window set will always be much more flexible than with one monster layout. And if you don´t like windows, change the layout in the current window. Users could even decide for themselves via a preference whether they prefer the "modern" one window behaviour or popups or several windows.


                        Third: As to our experience the normal user isn´t able to really view and understand such large display of data. I only know such displays from the stock exchange where people look at x curves at the same time. But these screens may be dashboards at its best, but no working screens for input of data.

                        • 9. Re: How to speed up FM12 layouts for faster screen redraw ?

                          I have to agree with Lee on this. While all your suggestions are appreciated and well thought out just the idea that many of us have to redesign the UI in the *hope* that it may speed things up in 12 is infuriating as Lee says. I don't think there really is a precedence for this sort of thing in the database design world ie having to redesign your solution to work around short coming of new release. It's clear this release was "style over substance" and while that may be fine for some people it's not for me, my UI design was settled years ago and while some of the new design tools are nice they don't add the value to my solution that me or my customers were looking for.


                          I've already got my strategy for getting the speed back from 11, don't upgrade to 12. I'm very happy with 11 (and a lot happier with it now since 12 was released) and can ride that horse a long way until either FMI releases a product that is actually useful or I learn a new platform which every comes first, which to intex's point I think will take a while since FMI had plenty of time to get the speed issue addressed and they didn't and released it anyway.

                          • 10. Re: How to speed up FM12 layouts for faster screen redraw ?
                            Stephen Huston

                            I offer a few comments on speed issues  reported with FM12:

                            1. Yes, FM12 is slower on some things than was FM11, but
                            2. FM12 is much faster on some things than was FM11, especially WAN performance -- a huge plus for the product.
                            3. Conditional formatting is essentially a type of unstored calculation which must evaluated every time the screen is redrawn. The more of these you have set to evaluate, the slower it is, and, yes, this is one of the areas where FM12 is slower than 11.
                            4. Screen redraws in general probably are slower in FM12 than 11 because of the interpretation of embedded CSS code, which is a little like having to evaluate an unstored calc to determine how to format and redraw. This exists only in 12, not 11, so it also adds to refresh time. The more objects there are on the layout, the slower I would expect the CSS to be in rendering.

                            None of this is really suprising once you consider what is now going on behind the scenes with layout rendering. FM12 is different than earlier versions. FM11 broke some older things which FMI flagged for deprecation many years before 11 was released, and those of us with converted solutions which still used some of those old behaviors had to spend time fixing problems which appeared only after FM11 was put into service. Was FM11 to blame? Doesn't matter.


                            Many of us have seen all of this before. We've learned to expect issues with every version change. It's unpleasant, and some people choose to become version-skippers or slow adopters because of  a version's impact on their specific solution(s). It's just more dramatic with a file-structure change because you cannot back out as easily.


                            Someday down the road we will all need to use computers which simply won't run versions earlier than "X", so, yes, the change is eventually forced on us all. Luckily such obsolescence tends to come only years after a version is available, and we've had time to adjust to it.


                            Meanwhile, report the problems, but try to react as if we are all learning a new system rather than being handed nothing but problems. Workarounds? I consider FileMaker software to BE a workaround for managing otherwise hard-to-use data. It's a really Great workaround!

                            • 11. Re: How to speed up FM12 layouts for faster screen redraw ?

                              Thanks, Stephen, for being a voice of reason.


                              I'd just like to add that I just upgraded my web site from 11 to 12 and have observed significant performance improvement with the PHP API. I've not seen that mentioned yet, but my provider stood up a 12 server for me for testing, and I was, quite simply, blown away.


                              So the internal engine has apparently been adjusted to work quite a bit better with the web. I think this is also a boon for the product.


                              Just my $0.02.



                              • 12. Re: How to speed up FM12 layouts for faster screen redraw ?

                                Hi Mike:


                                This makes sense.  While we are harping on the issues with the UI, FMI has done a massive amount of work on the Server which has almost no UI.   With the advent of full 64 bit capability and significant work to speed data coming to and from the FM Database, PHP should be faster all other things being equal.   I would also expect IWP to be faster, as the UI enhancements have not been fully deployed in IWP at this time, but the underlying database improvements are there.  Same with CWP and ODBC access.  We need to give FMI kudos where they have well earned them!




                                • 13. Re: How to speed up FM12 layouts for faster screen redraw ?

                                  I respect and appreciate everyone's opinion here and we all have our own perspective on things. Some people view 12 as the glass being half empty, some half full while I view it as a glass full of holes so you never know what to expect. Some things are faster, some things are slower, some things there are no difference.  Sure there are reasons for all of this well documented and understood but from my perspective the reasons for the performance issues are irrelevant, they exist and it's a real problem. If an important area or function of your solution is noticeabley slower it doesn't really make any difference that some other area may be a lot faster.


                                  It's the inconsistent nature of the performance issues that are so frustrating and frankly I can't remember a release that was so inconsistent in it's behavior so I don't really buy the arguement that these sorts of complaints or performance issues happen during every release, since the .fp7 platfrom was pretty stable for many years.


                                  If you are the type of person that wants to wade into the performance mine field that is 12 then God bless you and your customers for going down that road. I don't have the time for that nor is anyone going to pay me to do that. Many peole enjoy being on the "bleeding edge" of technology and thank God for them.  I choose to sit out the blood letting of 12 until FMI demonstrates that the new 12 platform can deliever consistent results across all areas of the product line.

                                  • 14. Re: How to speed up FM12 layouts for faster screen redraw ?



                                    Forgive me for repeating, but please be patient.  This situation will improve.  I've been floating around here for awhile now, and I've certainly had my times where I have been vocally POd with things that have or haven't happened with Filemaker, so I understand your frustration.  I've gotten good tonque lashings from Filemaker PMs (sometimes undeservedly, sometimes so).   I can tell you, I believe fully the class is half full.   Hang in there a bit and give these folks a chance to work things through, and I believe they will address most of your concerns.




                                    1 2 3 Previous Next