Bug in zooming effect


Author
Message
AKrishna
AKrishna
Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)Esteemed Member (2K reputation)
Group: Forum Members
Posts: 52, Visits: 174
Hi all,

we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text.

In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions.

Specifically (I will refer to lines in the script here to hopefully make it easier to follow):
Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display.

When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122).

Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part.

On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5.

We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5.

Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440).

Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/

Attachments
4.jpg (5 views, 346.00 KB)
Dave
Dave
Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)Supreme Being (937K reputation)
Group: Administrators
Posts: 11K, Visits: 70K
AKrishna - 6/2/2021
Hi all,

we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text.

In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions.

Specifically (I will refer to lines in the script here to hopefully make it easier to follow):
Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display.

When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122).

Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part.

On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5.

We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5.

Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440).

Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/

> the target word flickers in and out of visibility randomly during the zooming effect

Not seeing this under Inquisit 6.4.2 on not particularly beefy systems (e.g. a ca. 2013 ThinkPad T430 with a 3rd generation Intel Core i5 and 8GB of RAM).

The image has a 16:9 aspect ratio (1920 x 1080 pixels). Your display has a 16:9 aspect ratio (3840 x 2160 pixels), too, so this shakes out. Since the inherent aspect ratio of the image will not be distorted, you should expect to see artifacts on displays that are not 16:9, i.e. the image cannot cover the screen fully (e.g. 1680 x 1050 is 16:10).

Here's an example when running at a 16:10 resolution: