When does it redraw? (excessive flashing)

[kennedy]

I am having some problem with flashing... FMP blanking parts of my layout and redrawing them (rather than just redrawing over the existing such that you don't notice it).

For example, as I step from record to record in my list layout, the majority of my layout does not get redrawn... it looks nice and stable. In contrast, my tab bar flashes... it gets blanked and then redrawn each time.

In my List layout, the body and the column titles are stable... except the sort buttons in the column headers flash (along with the tab bar).

Q: Anyone know what causes such flashing (blanking and redrawing)?

Note that this is NOT a problem of scrolling fast, as another thread discussed... I am just going to next record... one button press. It might be related to merge fields, though some of what's being redrawn is just graphics. There is a field under some of the graphics that perhaps is popping forward and then getting drawn back over... but all those things seem to be in other places on the same layout NOT causing flash.

Any insight would be greatly appreciated.

Thanks.

[The Bridge]

I think the flashing problem is due, in part at least, to the arrangement of elements on your layout. That is, FileMaker draws the elements in order from back to front. I had a situation in which a layout with a portal was redrawing poorly, especially when many related records were displayed in the portal. The rest of the layout would wait for the portal rows to appear before drawing. The solution was to select the portal and the fields contained within and bring it to the front. Now the rest of the interface draws before the portal, which redraws when the related records are gathered. While there's still a noticeable flash, it looks a little more natural to have the portal flash instead of the rest of the layout.

Hope this helps.

[kennedy]

Yes that helps. That's a bit 80's, I must say. But that does explain things somewhat. However, some of my elements are NOT doing that.

For example, my column headers are a long gray OSX-aqua-style bar underneath text labels and round aqua buttons, the latter underneath fields that label those buttons. So, if it redrew from bottom up, all the labels and buttons would flash away when the bar drew and then reappear when they drew. That doesn't happen.

But my tabs are a transparent field under aqua graphics under merge-field labels which have been made into buttons. These completely flash away... as if that transparent field in back is being drawn as solid background and then everything else re-drawn. Ugly.

As another example, in the body of my list, I have solid white box under gray border lines and all the data fields. If it redrew from back, the solid white box should cover the fields until they are re-drawn. But that doesn't happen. No flash there at all.

So, while I don't doubt your answer... I think there's more to it... such as criteria on when it chooses to redraw from the bottom as opposed to just updating what's changed. Hence my question.

Does anybody know when its supposed to re-draw and when its not?

Thanks.

[BobWeaver]

This was discussed at length in this thread:

http://www.fmforums.com/threads/showflat.php?Cat=&Board=UBB46&Number=35082&page=6&view=collapsed&sb=5&o=&fpart=1

Even though it says the problem occurs when scrolling, it is actually the same problem, and the solutions are the same (limited as they are), unless someone has come up with something better since then.

[kennedy]

This was discussed at length in this thread:

Yeah, I saw that thread... had already read it twice looking for clues... decided to summarize it here, and in doing so finally found the *key* point... on the very last suggestion made in that other thread. I started to toss the summary, but then thought it might be useful to someone... so, here's my summary of that thread with a few responses mixed in. If you want to just skip to the punch line, go to the bottom (the last quote)...

The flash is very much dependent upon the complexity of the layouts and the redraw speed of the computer. It'll never be completely removed.

Just FYI... this is very much fixable by FMP... something taught in the very first CS course on graphics in college... you draw off-screen, and then paint the result on-screen. Zero flash... no matter how complex the graphics or how many layers. But, since I'm definitely committed to FMP, that's somewhat beside the point... the question is how best to avoid FMP's bad behavior.

Here's suggestions made in that thread:

The Freeze Window script can prevent a lot of "flashing" while scripts are running

This flashing is indeed user error, not FMP badness... Freeze Window is the solution to it... but it is not the issue for me. No scripts involved in my flashiness.

So, for such scripts get into the habit of creating a layout without any fields (except for global fields to show progress), I then use a counter which divides the number of records to be changed by 100, and then increases as the script progresses, thus I can have a status bar running through from 10 to 100%.

This is also good advice for long-running scripts, though again not the issue for the flashing I am concerned with.

Make sure that no objects are touching other parts or overlapping, for example, a field in the list touching the footer will cause sloppy-flashy redraws.

Question: Isn't it necessary for the objects in the list to overlap the footer by one pixel?? That seems to be my experience... if I don't, then I get one pixel gaps between the rows of my list.

However, in any case, that's not causing my flash... the list isn't flashing at all. It looks good.

Another trick is to use a script to go to the list layout and then to go to record one, then to the last record and then back to record one.

This preventing flash due to disk delays for things not cached. This was probably a bigger issue years ago. But in any case, has no affect on the flashiness I am seeing. It does it without accessing different data than already on the screen.

If you make the name of the field short like <<N>>, it won't overlap as much other stuff, and it should reduce the flashing somewhat (at the expense of self explanatory field names unfortunately).

Good advice, though not sure if I agree it makes it less noticable in many cases... rather, it makes the layers/objects more evident as their edges appear in the flashing. I actually find it uglier that way.

But the real question remains: *when* does it repaint under fields? More on that in a moment...

Try setting the background colour of the merge field to be the same as the background. I have found this can reduce the flashing.

Ahhh... This might indicate that if the object on top is solid and it is just redrawing that object, then it need not bother redrawing the object below. In that case, the flashing might be prevented.

Time for some experimentation...

Sure enough, by changing my current date merge field to have a solid background, it stopped needing to redraw the object below it and then that text object... flash gone!! The other areas that were not flashing all had solid backgrounds already. Theory holding well.

Sooooo....

SOLUTION TO FLASHING

To solve flashiness, get rid of all transparent data fields and merge fields! If you get rid of all transparent data fields, I think you get rid of all flash due to FMP (you can still get flash via bad scripting; use Freeze Window to stop that).

If you can't get rid of some transparent fields, then take extra care to make sure they overlap as few object as possible... and that the objects they do overlap with overlap with as few objects as possible... and so on. Because the flash is a bit like a virus... by forcing an object to redraw, you force all the objects overlapping it to redraw, and so on.

But that leads to some other questions, which I'll ask in a new thread...