![]() I tried messing with waitBlanking and it didn’t change anything.Īlso, with regard to Pyglet, I have at least a faint sense of why it might be failing so catastrophically. So, GLFW may be able to solve the problems I was having, but the big stumbling blocks now are 1) it needs to be much, much easier to install (ideally part of the psychopy installation process) and 2) it needs to be able to update multiple active windows. It creates a window on the retina display as well, but it’s blank. However…the thing about updating only the most recently created window still applies. I’ve confirmed that this is glfw doing the heavy lifting, switching it back to pyglet with this very setup it fails like it always did. Trying to use the multi-screen version with an external monitor connected via HDMI: It fixes the weird behavior I was getting from pyglet! It renders perfectly on the external monitor, right place, right size, right everything. It looks like it only updates the most recently created window, and while it creates both windows, it does not update or track events for the first one. Trying to use the single-screen version with no external monitor: Creates two windows but only animates one of them. This is pyglet’s usual behavior when confronted with a nonexistent second screen. Pyglet, for comparison, just creates both windows as though you’d run the single-screen version. Trying to use the multi-screen with no external monitor: Creates only one window, but animates properly. Then I tried running the screensAndWindows.py demo with glfw backends. Woo! Question: Should I just put in a pull request for that one or is that technically not PsychoPy’s problem? In any case, after updating the glfw module’s init file to include /opt/local/lib in its the list of search paths in _get_library_search_paths() (lines 167-168), “import glfw” in PsychoPy’s python shell now works. Among other things, I discovered that the dylib file that PsychoPy goes looking for is in /opt/local/lib, not /usr/local/lib. This was nontrivial and not something that I could possibly recommend to anyone who isn’t a power user. I finally wrestled glfw into place on my mac. you may be interested to hear how glfw is working here. Still on high sierra, now using the most recent version of PsychoP圓 (which is great). OK, so I’ve got some news about this, some good, most confusing. When both windows are on screen 1, while it reports that the two windows should be adjacent (as when both are on screen 0), they are not:.When both are on screen 0, both report 800, 600. This is the same as it reports when winL is on screen 0 and winR on screen 1. winL reports 800, 600 (which would be the expected “size” if it were on a retina display, because of the doubling) and winR reports 400, 300. When I put both windows on screen 1, they report different sizes.When I put winL on screen 0 and winR on screen 1, both windows appear, but only winL shows the stimuli, while winR remains blank. ![]() I haven’t tried this on the beta yet, so there’s a chance it may have been fixed, but it doesn’t look like window has changed in any relevant way… Notably, it does not…īasically, I ran the “screensAndWindows” demo with a few permutations after noticing that stuff opens in weird places and at weird sizes on a second screen when the primary monitor is a retina display. By default new windows are opened at 0,0, and it looks like that’s being mapped to the top-left corner now instead of the center of the screen. This occurs whether I open the window on screen index 0 or 1 (notably, when opening on screen index 1, it puts it in the top left of THAT screen). When I open a window, with or without fullscreening, it centers it on the top-left corner of the screen. I’m on a 2017 Macbook Pro with retina display. Retina display windows opening in wrong place in 1.90.0 Py2 version Coding
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |