"onWindowResize, reflow a lot of form fields" is sluggish. Wonderin' how the cool kids do this?


#1

Hi,
In this example RP file, I have about 45 form fields that reposition themselves based on window.width.
Simple enough, but it seems to take Safari a few seconds to render (and occasionally crash), onWindowResize.

I have a knack for building things the hardest way possible, so is there a smarter way you cool cats would build this sorta thing?
( I thought about going about it with adaptive views / breakpoints, but this example file is going to have 90 fields, instead of 45, next week; and 90 fields x 4 adaptive views is a lot of work.)

Thanks Axure hive-mind!
-John
crashTestBurrito.rp (260.9 KB)


#2

Adaptive views. Your solution is trying to recalculate all that many, many times per second every time you resize. Either debounce the Resize event so you’re only trying to recalculate every second or so.


#3

Thanks nkrisc! Any chance you can point out where or how I’m making it recalculate more times than necessary (“debounce”)? Or what I substitute instead? (the actual number of fields will be 90 or so, so I don’t think I want to do multiple adaptive views for a hundred fields. maybe I’m not seeing something?)


#4

The OnWindowResize event fires every time the window resizes. And if you resize it quickly, it’s resizing many times per second most likely, thus firing the event many times per second, thus recalculating everything many times per second.

Debounce means including some logic to not calculate it every time the event fires, but fewer times. You might use a timestamp from the last time it fired and compare it each time the event fires to know if its time to recalculate or not.


#5

Many thanks for the explaino! Will start with a conditional based on “IF CurrentSeconds ≠ LastTimeStampSeconds” of some sort to restrict calculations to per-second.

Much appreciated!


#6

That’s the gist of it, yeah. Unfortunately I no longer have the file, but I did just this years ago and it worked like a charm.

[[Now.valueOf()]] is I think what you’ll want to use for the timestamp. It’s in milliseconds, so keep that in mind.


#7

Thanks nkrisc.
Just seeing your Now.valueOf suggestion, was under a deadline yesterday.

Yesterday (not having seen your suggestion), I went with Now.getMilliseconds :
IF [[ Now.getMilliseconds() ]] > [[ Now.getMilliseconds() +60 ]]

Do you think Now.valueOf would reduce browser-load?
And do you think there’s a better IF conditional for triggering a moving of the fields?


#8

I don’t know what would work best, you’d just have to try it out and see. Shouldn’t really be any different.

Where the performance difference comes in is comparing timestamps every time the resize event fires is way faster than moving 90 widgets every time the resize event fires.

As for how you compare and what for the timestamp, I don’t think you’ll really notice any difference in how you technically accomplish that.


#9

you were right. I’m going adaptive now. much thanks!


#10

Hey nkrisc, one final question:
In your first reply, you mentioned my problem was the resizing, many, many times per second.
How were you able to determine that so quickly—is there something in Axure’s console or in your browser’s Inspect Element function that you used?
Thanks again!


#11

It’s just how the WindowResize event in JavaScript, and by extension in Axure (because I don’t think they throttle it) works.

You can also see it in Axure’s console tab on the sitemap. Add a case to the OnWindowResize event and resize your browser. You’ll see how many events fire. Then multiply that times lots of expensive actions like moving 90 widgets and that’s how I arrived at the conclusion.


#12

Ok thanks, I would benefit from learning how to use azure’s console to troubleshoot then. Much appreciate it!


unlisted #13