Change of draw order for shape stim?

Online experiments
1

URL of experiment: https://pavlovia.org/run/robinsonj/beachsquares_task

Description of the problem:
Problem original posted on a PsychoJS github commit (reference is made to this commit): 9f987d97a6419463065218e84b5cd091470df298

We’ve been experiencing issue when running our study (pscyhoJS 2020.2) on Pavlovia today.

These issues seems to relate to issue with update order within frames.
Essentially background and foreground polygon’s are placed in the wrong order following frame updates.
Before running our experiment we performed extensive pilotting. This issue was not present during pre-study piloting (as at the 22nd November).

Specifically in our experiment polygons locations are updated on every frame in relation to mouse movement, the foreground was kept grey (originally I found I had to reassert this on every frame to keep the draw order), and the background was changed consistent with the colour of the polygon that the participant selected (when the participants presses the keyboard). The idea being that participants get a background border that indicates their current selection.

Now a range of issues have arisen (hopefully these descriptions aid diagnosis):

-When the colour of polygons is assigned (within Begin Routine), there seems to be only partial assignment. ie. of 4 objects only 1 is coloured. The number assigned seems to vary (even when all are set for frame by frame update)? This does not appear to happen for text objects.

-When a key is pressed (should colour the outer edge background). The background is placed in front of the foreground (this was not happening before).

-When the key press is released the background colour (now switched back to grey) overwrites the foreground again (along with all other polygons on screen).

-In another part of the experiment participants perform a selection task for a range of polygons. Previously I used another polygon to border the polygon selection. Now it appears the draw order has changed such that the ‘border’ polygon is drawn on top of the polygon rather than underneath (such that it would have bordered the object). Again text objects still appear on top of the ‘bordering’ polygon.

Could this commit have resulted in an issue of this type? Or do think some other recent commit might be responsible? Most importantly we’re trying to track down exactly when this change might have happened so we can confirm the integrity of our data.

If this commit was involved (crossed fingers), our experiment data may yet be saved.

2

Hi,
This sounds like a very similar issue to the one I have where although my stimuli are set to redraw every frame, they are not being drawn in the order set in the builder and so one is always deing drawn on top (covering the others).

1 Like
3

Hi @robin0025, sounds like a bug on our end, please could you give me access to your repository so that I can take a closer look, here to help, s.

4

Hi @sotiri,

I’ve now given you access.
A couple of things to say:

  1. You will note I have been playing around with what was frame updated, since the error, to see if I could get the drawing order working properly, to no avail.
  2. If this is on your end please could you let me know as soon as possible when the change happened. As I say above this is really important regarding the integrity of the experiment data. Please could you include date, time and timezone, as the update I cite happened 6 hours after our final participant finished (between our lab in Australia, your UK office [I’m guessing?] and some participants in the US there is some potential for timezone confusion).
5

Dear @robin0025,

It is really unfortunate that recent PsychoJS performance improvements broke your study midway. Please accept our apologies for the mishap. You are right, the problem appears in cases where visual stimuli attributes, such as position or opacity, remain constant, but are set in Builder to update on each frame.

Library updates were brought in at the following dates and times:

2020-12-04 09:32 (UK)
2020-12-13 10:56 (UK)

But the later deployment should have had no effect in this context.

To address the issue one may call psychoJS.window._fullRefresh() at the very bottom of a routine. I have created separate code components to that end for the routines affected in your project. Is the support team fork working as expected? The fix is part of the .psyexp. Here to help, really sorry about this, s.

2 Likes
6

Hi @sotiri,

It appears these were brought in after my testing was complete?
I conducted testing between 22nd November & 30th November, so based on the dates you give these updates should not have effected my data collection? Therefore my data should be safe (?) and not have this error during collection. Please could you confirm that I’m correct?

Yes the support fork works as it should!
Thank for your expedient analysis of the issue!!

Best wishes,
Jonno

7

Hi @robin0025, alright, thank you, immensely sorry to have caused you stress and glad to hear the problem is gone. I have double checked with the engineer in charge and no other updates have been brought in between late November and now, the dates and times above are definite. In my layperson eyes, your project looks seriously interesting and original, many thanks for using PsychoPy to run your study and for your understanding as we iterate to improve our software, x

1 Like
8

Hi, @sotiri ! I am running into the same issue with my project when I deploy it online. The order of the stimuli looks great locally. But, nothing is right when deployed, even with the call you referenced above. Any advice you have would be great as a student’s thesis is on the line!

9

Hi @David_Cox, no problem, would it be possible the give me developer access to your project? Thanks, x