I want to make an 'SSVEP' flickering lines on the monitor using PsychToolbox.
By the way, when I made a 6Hz-flickering line, it sometimes disappeared: I guess there is some conflict between 6Hz-flickering stimulus presentation and the monitor refresh rate (60Hz).
How can I solve this problem?
If you could provide the code, it would be most appreciated.
In principle, you should wait for "vsync" (just before displaying a new 60-Hz frame), and then "flip" to the other (already filled) screen buffer.
Related
I'm new to scratch.
I have this code within a sprite, which works as expected without noticeable lags:
But, when I "export" the flickering into the 'flicker' block, it has a very nasty lag:
I created a special sprite in order to easily "feel" the lag, with this code:
This ball smoothly moves, until (every 5 seconds) there is the flickering effect and it stops for 1 second or so.
Can anyone give me a clue why it happens, and how to prevent it?
The project page is here.
Any assistance would be appreciated.
Let me start by pointing out that the problem does not occur when I launch your project.
I tried it in 5 different web browsers on 3 different devices with 2 different operating systems, and every time, the ball just kept moving.
However, I can make such an issue happen by enabling 'Run without screen refresh' in the 'flicker' block, as follows:
Right-click on the red 'define flicker' block.
From the context menu, select 'Edit'.
In the 'make a block' dialog, turn on checkbox 'Run without screen refresh', then click OK.
I suspect 'Run without screen refresh' claims all processing power, effectively blocking any other (concurrent) scripts.
My guess is, you already fixed the problem yourself by turning off 'Run without screen refresh'.
In general, 'Run without screen refresh' is a great way to reduce lag in scripts where speed is essential. But never use it in a script with 'wait' or 'forever' blocks, or it will cause lag.
When I build and debug with a breakpoint set ANYWHERE in the code, the simulator window stays all black and I can't see my label. If I build and debug without setting any breakpoints, I am able to see my label. Can anyone help? I would like to be able watch changes occur to my labels, buttons, etc. as I step through lines in the Xcode debugger. By the way, my program uses code to dynamically create and place my UILabel onto the main view.
Is everyone else able to see thier labels and buttons while debugging with breakpoints? I am new to iOS (4.2) development and Objective-C.
As long as you are halting the execution by using a breakpoint, no UI will be updated. So you can't debug in this way. Though you will be able to see the variables and properties. For example, in the debugger you can check whether the text property of label have changed after you set that, but there is no way that the UI will update until you continue the execution.
You'll need to post your run log to work out why your screen is black when you set a breakpoint. My suspicion is that you're setting a breakpoint before the draw cycle, but your question is a little unclear about that.
As far as your goal of seeing changes to the label as you step through the code, this suggests a misunderstanding of the drawing loop. As your code runs, it will make changes to the label data structures, and likely cause setNeedsDisplay: to be called on the label (this is generally called for you automatically when needed). When the next drawing cycle occurs, views marked for display will be redrawn. This will cause drawRect: to be called, but that still doesn't draw on the screen. It just draws into a buffer. After all the drawRect: calls are done, the buffer will be synced to the screen.
There is no point in this cycle that you can set a breakpoint on a method like label.text = #"newstuff" and expect to see it show up on the screen when you step over it.
Make sure to hit the little "continue" arrow after hitting the breakpoint (which may happen repeatedly). The Xcode Debug window has a larger continue arrow. Until you hit continue, the simulated OS will never get time in the UI run loop to update it's window.
I'm trying to investigate a very long start up time for my app and could use some help. It takes about 6-7 seconds to start up and that's just FAR too long. I'm not loading any data sets or anything, but the app is a calculator so my xib does have lots of buttons and button images.
I'd like to use Instruments (or something else) to analyze where all of the time is being spent so that I can optimize, but the documentation for Instruments isn't really giving me much on specifics of how to use it for this specific problem and/or how to interpret the results.
Do you have any suggestions for how to test this? A pointer to a tutorial on how to use Instruments for this? An iTunes U video or something else?
Any suggestions are welcome!
Kenny
Palimondo asked how I eventually solved my problem... it was a bunch of small changes and I'm not truly sure where the savings came in to play and I'll explain why below.
My app is a calculator, so it has a ton of buttons. I thought at first it must be the button loading causing the problem, but as I explained in the comments above to Paul, even if I loaded 0 buttons, that only shaved 1 second off of the start up time. After changing many small things, I was able to save 3 seconds off of start up time which was good enough.
I had a background image that was a nice textured-gradient-ish image. I reduced the file size on it (changed the texture, exported it with different options).
I went from loading 100 buttons up front (it's a calculator) to loading about 15, but attempted to do it in a secret fashion so the user wouldn't notice. About 50 of the buttons aren't visible to start anyway because you have to tap a Shift button to see them, so they were easy to lazy-load. The others are visible, but I figured that the user isn't going to tap most of those right at start-up because they need to hit some numbers first. So I left all of the number pad buttons and the Clear button in the xib so they are loaded on start up but removed everything else from the xib.
That left me with a big blank area on the screen and you could actually see the buttons filling in the blank area as I lazy loaded them (filling very quickly, but you could see the blank area and then all the buttons appear). So I updated the background gradient graphic to include images of the buttons. The buttons appear to be there, but they aren't, so unless the user taps a fake button within 2 seconds they never notice a problem... and usually they just try to tap that button again anyway and by then it usually has been lazy-loaded and therefore works.
Before doing any of the above suggestions:
Is this 6-7 seconds while running from XCode? Or from starting directly by tapping it on the iPhone?
Debuggers and instruments won't help you much here, since they just add to the overhead, and won't help as much in profiling because it poisons the data you'll see.
Edit:
In terms of profiling tools, you may want to look into using Shark:
http://www.switchonthecode.com/tutorials/using-shark-to-performance-tune-your-iphone-app
It's pretty simple to use in general. It's sorta self-explanatory.
Here are couple of suggestions:
do you need all those buttons loading up at once?
do you (over)use transparencies in your images?
are the images the exact size required? Stretching (resizing) takes time to compute
do you perform any operation that is blocking the main thread?
I would measure the startup time of an empty dummy app (maybe the XCode Window-based app template) on your actual device (debugger disconnected). Then start adding your initialization code, views and objects from your app into this dummy app until you find what's slowing the startup time the most.
I have an issue with one of my c# applications, it has a single form which is stretched over two monitors and works fine, however if I lock the screen and come back to it, the application reverts to a single screen view.
I was wondering if anyone had come across something like this before or knew why this was happening?
thanks
I think this happens because the second screen is disabled during the desktop is locked.
If you now log in again, the form will reinitialize it's position before the second monitor is activated again.
This small article might help you, to solve the problem :)
This is kind of weird, but I noticed that up to 40 percents of the rendering time is spent inside glAlphaFuncx. I know that alpha testing is very expensive, but the interesting thing is I do not use it :) No single place of code uses alpha testing, neither do I invoke this function in any other way.
I also checked GL layer for blending on other sorts of stuff which might cause this to happen but it is what it is.
So, if anybody knows what might cause glAlphaFuncx to appear on the performance trace of CPU Sampler, I would be glad to hear it :)
Update: fixed the screenshot link: http://twitpic.com/2afxho/full
Update 2: the function that leads to invokation of glAlpaFuncx contains a single line:
[context presentRenderbuffer:GL_RENDERBUFFER_OES];
Update 3: I tried setting the breakpoint inside this function, but it seems it haven't been invoked at all. I guess profiler is screwed up here...
It's weird that this function appears on a profiler trace, as you say you aren't using it. Try setting a breakpoint in glAlphaFuncx to see from where it is being called.
But anyway, that should not be a problem, glAlphaFunc will just set a state in the GL server side, it doesn't (or should) do any more processing than that. It shouldn't be a performance problem, maybe it's a bug in the GL implementation or in the profiler.
To be sure, you can disable alpha test with glDisable(GL_ALPHA_TEST).
From what I can see, glAlphaFuncx could just be taking the hit for setting up the rendering or pushing the pixels. It could be that it is run either first or last in the rendering.
Do you have an actual performance problem, or are you just trying to find pieces of code to slice off / optimize?
If so, you should set a breakpoint in glAlphaFuncx and see where it is called from and why. To do this, just bring up the debugger console and type "break glAlphaFuncx".
Have you tried explicitly disabling the use of alpha channels?
glDisable(GL_ALPHA_TEST);
http://www.khronos.org/opengles/documentation/opengles1_0/html/glEnable.html
Regardless of system, this sort of behaviour -- time spent presenting what's been drawn -- almost always indicates that the GPU is the bottleneck. Either you are drawing too much (if the framerate is a problem), or the CPU isn't doing enough (if the framerate is fine).
Actually, there's one other possibility -- that the amount of GPU work is fine, but the system is waiting for some kind of vertical retrace period. (That seems unlikely on a device that only ever has an LCD, and doesn't support a raster scan display, but maybe things still notionally work that way internally.) The upshot is still the same as far as the amount of CPU works goes, though, in that you've got time to do more stuff without affecting the frame rate.
I can't explain exactly why glAlphaFuncx specifically is appearing in the call stack, but if it doesn't appear ever to be actually getting called then I'd consider it a red herring until proven otherwise.