By AKrishna - 6/2/2021
Dear all,
I ran into what is presumably an environmental issue recently when testing an experiment for online use. Specifically, I have a word recognition experiment in which a progress bar fills up gradually - depending on the condition, it either becomes filled with red as participants make more errors or it becomes filled with green as participants make more correct responses (condition assigned by subject number). The feedback is actually bogus in that the bar will never actually fill up (given an expected range of participant response accuracy), but should approach being full over the course of the trials.
So far so good, this all works as expected on my computer as well as on that of a research assistant. However, a second research assistant mentioned that the bar wasn't filling up on her screen in either condition and was able to provide screenshots. I have attached a stripped-down version of the code for reference, but the essence is that I'm using a <shape> element with a variable size parameter to fill the bar over time. Is there any known environmental condition that might cause this to fail in Inquisit? If so, is there any setting I might change (in <defaults> for example) to prevent this from happening?
Broad question, I know. Sorry I don't have more information - getting precise technical specs from the RA's computer is even more difficult via Zoom, unfortunately. She was running Windows (as was I and the other tester), if that helps any.
|
By Dave - 6/2/2021
+xDear all, I ran into what is presumably an environmental issue recently when testing an experiment for online use. Specifically, I have a word recognition experiment in which a progress bar fills up gradually - depending on the condition, it either becomes filled with red as participants make more errors or it becomes filled with green as participants make more correct responses (condition assigned by subject number). The feedback is actually bogus in that the bar will never actually fill up (given an expected range of participant response accuracy), but should approach being full over the course of the trials. So far so good, this all works as expected on my computer as well as on that of a research assistant. However, a second research assistant mentioned that the bar wasn't filling up on her screen in either condition and was able to provide screenshots. I have attached a stripped-down version of the code for reference, but the essence is that I'm using a <shape> element with a variable size parameter to fill the bar over time. Is there any known environmental condition that might cause this to fail in Inquisit? If so, is there any setting I might change (in <defaults> for example) to prevent this from happening? Broad question, I know. Sorry I don't have more information - getting precise technical specs from the RA's computer is even more difficult via Zoom, unfortunately. She was running Windows (as was I and the other tester), if that helps any.
I've tested the script on a bunch of Windows systems and it's working fine, so it's probably something particular about the RA's computer. At a minimum, make sure the computer is running a supported Windows version (Inquisit 6 officially requires Windows 10) as well as the latest Inquisit 6 version.
|
By AKrishna - 6/2/2021
Hmm, I feared as much. I'll get her to test the experiment again (maybe with a fixed canvas ratio or something, just in case) and use the screencapture option to take a few screenshots near the end of the experiment. If she encounters the same error, it should be visible on the screencaptures - that way I can any exclude people who have the same error, at least.
If I do this, are there any specs I should log in Inquisit's data file? If the error does reoccur, perhaps my logs could help you squash the bug in the future.
|
By Dave - 6/2/2021
+xHmm, I feared as much. I'll get her to test the experiment again (maybe with a fixed canvas ratio or something, just in case) and use the screencapture option to take a few screenshots near the end of the experiment. If she encounters the same error, it should be visible on the screencaptures - that way I can any exclude people who have the same error, at least. If I do this, are there any specs I should log in Inquisit's data file? If the error does reoccur, perhaps my logs could help you squash the bug in the future.
I would log OS version as well as the various display properties.
https://www.millisecond.com/support/docs/v6/html/language/elements/computer.htm
https://www.millisecond.com/support/docs/v6/html/language/elements/display.htm
|
By AKrishna - 6/4/2021
Quick update: fixing the canvasratio didn't help. I'll do a pilot run of around 40 people and see whether the error occurs again - if it does, I'll post updates here.
|
By AKrishna - 6/10/2021
Another quick update: I've put data collection on ice, as the issue appeared on another tester's laptop. That makes 2 of 5 systems I've tested it on, which is worrying.
My RA's data also didn't upload to the Inquisit server for some reason (there may be a firewall issue she was unaware of), but I've since been able to confirm that screenshots capture the issue. I'll try to sit down with the RA and narrow the problem down, but any help would be appreciated, as this project is fairly time-critical.
I suspect it may have something to do with the calculation of the progress bar's length somehow leading to invalid pixel values on certain systems. Will update if I find anything new.
|
By Dave - 6/10/2021
+xAnother quick update: I've put data collection on ice, as the issue appeared on another tester's laptop. That makes 2 of 5 systems I've tested it on, which is worrying. My RA's data also didn't upload to the Inquisit server for some reason (there may be a firewall issue she was unaware of), but I've since been able to confirm that screenshots capture the issue. I'll try to sit down with the RA and narrow the problem down, but any help would be appreciated, as this project is fairly time-critical. I suspect it may have something to do with the calculation of the progress bar's length somehow leading to invalid pixel values on certain systems. Will update if I find anything new.
(1) Are the testers' systems at issue here by any chance also among the systems showing the zoom problem with your AAT script?
(2) Regarding
"I suspect it may have something to do with the calculation of the progress bar's length somehow leading to invalid pixel values on certain systems."
I see no obvious reason how this could be the case, but to rule this in or out, you could either round the calculated pixel value to the closest integer:
/WordRecognitionProgressBarLength = concat(round(values.WordRecognitionProgressBarLength),"px")
Or use ceil() if you want to round up exclusively (floor() for rounding down):
/WordRecognitionProgressBarLength = concat(ceil(values.WordRecognitionProgressBarLength),"px")
Or use ipart() to throw away the fractional part:
/WordRecognitionProgressBarLength = concat(ipart(values.WordRecognitionProgressBarLength),"px")
(3) Another thing to rule in / out: Per concat() the expression returns a string, so I'm wondering whether there's some type confusion involved. Rather than using concat(), try e.g.
/WordRecognitionProgressBarLength = 1px*round(values.WordRecognitionProgressBarLength)
|
By AKrishna - 6/10/2021
Oh, cheers, those are good ideas! I'll make sure to test them ASAP.
With regard to the zooming bug: one of the two affected systems definitely overlaps; I don't know about the RA's computer, as she didn't test the zooming paradigm. I'll ask her to do so when we get together.
|
By Dave - 6/10/2021
+xOh, cheers, those are good ideas! I'll make sure to test them ASAP. With regard to the zooming bug: one of the two affected systems definitely overlaps; I don't know about the RA's computer, as she didn't test the zooming paradigm. I'll ask her to do so when we get together.
> With regard to the zooming bug: one of the two affected systems definitely overlaps;
That's interesting, as the two issues have some similarities (i.e. in both cases some systems fail to draw an object that is constantly adjusted in size to the screen). This may point to the some underlying cause, though I'm still not sure what that is (both issues do not show on any of our systems). It would be good to know the specs for the systems at issue here as well, insofar as you have them available or can easily obtain them.
|
By AKrishna - 6/14/2021
+x+xAnother quick update: I've put data collection on ice, as the issue appeared on another tester's laptop. That makes 2 of 5 systems I've tested it on, which is worrying. My RA's data also didn't upload to the Inquisit server for some reason (there may be a firewall issue she was unaware of), but I've since been able to confirm that screenshots capture the issue. I'll try to sit down with the RA and narrow the problem down, but any help would be appreciated, as this project is fairly time-critical. I suspect it may have something to do with the calculation of the progress bar's length somehow leading to invalid pixel values on certain systems. Will update if I find anything new. (1) Are the testers' systems at issue here by any chance also among the systems showing the zoom problem with your AAT script? (2) Regarding "I suspect it may have something to do with the calculation of the progress bar's length somehow leading to invalid pixel values on certain systems." I see no obvious reason how this could be the case, but to rule this in or out, you could either round the calculated pixel value to the closest integer: /WordRecognitionProgressBarLength = concat(round(values.WordRecognitionProgressBarLength),"px")
Or use ceil() if you want to round up exclusively (floor() for rounding down): /WordRecognitionProgressBarLength = concat(ceil(values.WordRecognitionProgressBarLength),"px")
Or use ipart() to throw away the fractional part: /WordRecognitionProgressBarLength = concat(ipart(values.WordRecognitionProgressBarLength),"px")
(3) Another thing to rule in / out: Per concat() the expression returns a string, so I'm wondering whether there's some type confusion involved. Rather than using concat(), try e.g. /WordRecognitionProgressBarLength = 1px*round(values.WordRecognitionProgressBarLength)
OK. We just tried this out now - rounding the number (I used ceil) solved the issue for my RA's system. In the interest of inquiry, we also tried the 1px*value solution and this DIDN'T solve the problem. So it seems as though non-whole number pixel values cause a problem on some systems and not on others. This might indeed be related to the other (zooming) issue as well, as this RA experienced the same flickering issue described in that thread on her system.
I asked her to give me her system specs (tldr at bottom):
Betriebsystemname Microsoft Windows 10 Home
Version 10.0.19042 Build 19042
Zusätzliche Betriebsystembeschreibung Nicht verfügbar
Betriebsystemhersteller Microsoft Corporation
Systemname DESKTOP-OR00U6U
Systemhersteller LENOVO
Systemmodell 81TK
Systemtyp x64-basierter PC
System-SKU LENOVO_MT_81TK_BU_idea_FM_IdeaPad C340-14IML
Prozessor Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 2112 MHz, 4 Kern(e), 8 logische(r) Prozessor(en)
BIOS-Version/-Datum LENOVO CKCN12WW(V1.02), 08.11.2019
SMBIOS-Version 3.1
Version des eingebetteten Controllers 1.12
BIOS-Modus UEFI
BaseBoard-Hersteller LENOVO
BaseBoard-Produkt LNVNB161216
BaseBoard-Version SDK0J40700 WIN
Plattformrolle Mobil
Sicherer Startzustand Aus
PCR7-Konfiguration Erweiterung zum Anzeigen erforderlich
Windows-Verzeichnis C:\WINDOWS
Systemverzeichnis C:\WINDOWS\system32
Startgerät \Device\HarddiskVolume1
Gebietsschema Deutschland
Hardwareabstraktionsebene Version = "10.0.19041.964"
Benutzername DESKTOP-OR00U6U\anton
Zeitzone Mitteleuropäische Sommerzeit
Installierter physischer Speicher (RAM) 16,0 GB
Gesamter physischer Speicher 15,8 GB
Verfügbarer physischer Speicher 7,78 GB
Gesamter virtueller Speicher 21,3 GB
Verfügbarer virtueller Speicher 10,7 GB
Größe der Auslagerungsdatei 5,50 GB
Auslagerungsdatei C:\pagefile.sys
Kernel-DMA-Schutz Aus
Virtualisierungsbasierte Sicherheit Nicht aktiviert
Unterstützung der Geräteverschlüsselung Erweiterung zum Anzeigen erforderlich
Hyper-V - VM-Monitormoduserweiterungen Ja
Hyper-V - SLAT-Erweiterungen (Second Level Address Translation) Ja
Hyper-V - Virtualisierung in Firmware aktiviert Ja
Hyper-V - Datenausführungsverhinderung Ja
Display
Name Intel(R) UHD Graphics
PNP-Gerätekennung PCI\VEN_8086&DEV_9B41&SUBSYS_3F1917AA&REV_02\3&11583659&1&10
Adaptertyp Intel(R) UHD Graphics Family, Intel Corporation-kompatibel
Adapterbeschreibung Intel(R) UHD Graphics
Adapter-RAM 1,00 GB (1.073.741.824 Bytes)
Installierte Treiber C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_440392e76b44e849\igdumdim64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_440392e76b44e849\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_440392e76b44e849\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_440392e76b44e849\igd12umd64.dll
Treiberversion 26.20.100.7985
INF-Datei oem44.inf (Abschnitt iCML_w10_DS)
Farbebenen Nicht verfügbar
Farbtabelleneinträge 4294967296
Auflösung 1920 x 1080 x 60 Hz
Bits/Pixel 32
Speicheradresse 0xB0000000-0xB0FFFFFF
Speicheradresse 0xA0000000-0xAFFFFFFF
E/A-Port 0x00003000-0x0000303F
IRQ-Kanal IRQ 4294967256
Treiber C:\WINDOWS\SYSTEM32\DRIVERSTORE\FILEREPOSITORY\IIGD_DCH.INF_AMD64_440392E76B44E849\IGDKMD64.SYS (26.20.100.7985, 24,76 MB (25.961.328 Bytes), 16.07.2020 13:24)
tldr:
Windows 10 Build 19042
Intel Core i5-10210U
16 GB RAM
Intel UHD Graphics, driver version 26.20.100.7985
Resolution: 1920 x 1080 x 60 Hz
I will be able to test whether the issue is resolved by rounding on the other system that experienced it in about an hour (hopefully).
I will copy these specs to the other thread as well!
|
By AKrishna - 6/14/2021
OK, some interesting results. The issue was also fixed on the other affected system (specs: https://www.millisecond.com/forums/Attachment2549.aspx and https://www.millisecond.com/forums/Attachment2550.aspx), but this time, BOTH rounding (with ceil) AND using the 1px*value method solved the issue. Strange. For safety, I'll code my experiment to use both (i.e. 1px*ceil(value)) and get screenshots. I'll also collect system data from participants so that you can get a bit of a better handle on this. Time to amend the informed consent...
|
By erikb - 6/15/2021
The problem turns out to have been a mix of the old style text manipulation to convert the WordRecognitionProgressBarLength to size and the German locale on some of your systems. Unfortunately, in this case, the German locale was creating a number like "4,137" that matches the display expectation for the locale while Inquisit the inquisit parser expected "4.137". This is why when you concatenated px to then end and used it as a size it failed.
For this particular script in Inquisit 6 you'll get the best results by using the modern display.getpercentx() method:
/WordRecognitionProgressBarLength = display.getpercentx(values.WordRecognitionProgressBarLength)
Thanks and Enjoy,
Erik
|
|