Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Initializing trials slow on Droid back-end

Hi all,

It's been a while since i used OpenSesame but i really dig the new look (and ofcourse all the new functionality that came along with version 3.0+)!

I'm currently making a associative priming task with the Droid back-end. Participants have to mark a consent form before they continue to the instructions. Directly after the instructions a round of practice trials start, which includes a set of .png files taken from the file pool. The instructions screen is presented with a text disply form, so the participants have to tap on a button to continue. For some reason the continuation takes ages (well, 20+ seconds...) when i test-run it in a windowed screen. And when i test-run it on my tablet it even seems like an infinity (60+ seconds...).

I've tried switching the form to regular sketchpad+touch response combination but to no avail. This led me to think that the pictures in the file pool might be the issue. The file pool consists of 28 pictures with a total file size of 1.67MB. This hardly seems demanding to me.

Then i checked an older but similar experiment i build earlier this year with version 2.7. Here, the lag does not seem to exist (in these durations). Am i missing something in the new version that might cause the lag?

Have a nice weekend,

Laurent

Comments

  • Hi Laurent,

    Good to see you back on the forum!

    In general, the most common cause for these excessive preparation delays is when you:

    • draw many elements to a canvas object; and
    • you don't specify auto_prepare=False; and
    • you use the expyriment backend.

    Could that be it? See also canvas.__init__().

    If that's not it, it would be best if you upload the experiment here so we can see what's wrong.

    Cheers,
    Sebastiaan

  • Hi Sebastiaan,

    Thanks for the prompt reply!

    draw many elements to a canvas object; and

    I'm only drawing Sketchpads with one or two elements. Two items in my sequence are rather large noise elements though. Could that be an issue?

    you don't specify auto_prepare=False; and

    At the moment i'm only using Sketchpad item instead of manually drawing my elements to a canvas. Is there a Sketchpad option for auto_prepare=False?

    you use the expyriment backend.

    Everything is build using the Droid back-end. The documentation from canvas.init() says that the auto_prepare=False parameter is ignored by the other back-ends?

    Cheers,
    Laurent

  • I'm only drawing Sketchpads with one or two elements. Two items in my sequence are rather large noise elements though. Could that be an issue?

    Yes, absolutely! What I would do is create a few bitmaps with noise textures, and use these in the experiment. Will that do as well?

    At the moment i'm only using Sketchpad item instead of manually drawing my elements to a canvas. Is there a Sketchpad option for auto_prepare=False?

    The sketchpad does this automatically. (And, in any case, it's not applicable here because you're not using the xpyriment backend.)

    Everything is build using the Droid back-end. The documentation from canvas.init() says that the auto_prepare=False parameter is ignored by the other back-ends?

    Correct.

    Cheers!
    Sebastiaan

  • Yes, absolutely! What I would do is create a few bitmaps with noise textures, and use these in the experiment. Will that do as well?

    After a few more hours tinkering with the paradigm this was the solution i found as well. But still, this is about the maximum i can demand of my poor Asus tablet.

    Thanks for thinking along!

  • edited December 2016

    Just to add for future references:

    • changing the picture file extensions from .jpg to .png did seem to help substantially, reducing the initiation time to approximately 20 seconds.

    • There also seems to be a significant lag after every trial. It takes approximately 1500-2000ms before the next trial is shown, regardless whether the participant provided an answer or if the timetout has been reached.

  • Thanks for posting this. Good to hear that it's workable now—but still odd that it's so slow, even after using bitmaps.

Sign In or Register to comment.