Re: Uneven V-sync

On 1/20/17, Edition Chamäleon <[email protected]> wrote:
> Hi there,
> is there anyone out there who has a clue why in my case (see above) SDL on
> Android gives such uneven iteration time, even if vsync is on and there is
> almost nothing drawn or calculated?  I'm running out of ideas here.
>
> Michael
>
>

Here's a few thoughts:

- On Android, SDL is (tragically) running on a background thread and
not the main UI thread. So when the vsync happens, it may not occur on
your thread. So you may not actually be measuring what you think you
are.

- Some graphics drivers may not block for the entire actual draw at
your RenderPresent call. So the draw call may return quickly/early,
and the under the hood, the video card does things asynchronously or
defers the drawing, perhaps to the real vsync. So again, you may not
be measuring what you think you are.

- In both the above cases, you are timing just the rendering call, and
not the time it takes to go through the entire game loop for that
frame. If the graphics system is rendering at a different time, you
skip measuring the real drawing time. Usually this results in faster
(unrealistic) framerates and makes the benchmarks look fishy. (I think
I remember Pixi.js BunnyMark did this and the reported numbers were
way over inflated than what was actually going on. I'm not sure what's
going on in your case, but I think you should also try measuring the
time between the start of each loop. I would not be looking for an
exact 16 ms, but I would be looking for numbers less than that.


- A very long time ago, I had to use a really poor C++ compiler with a
crap library implementation. ostringstream was ridiculously slow. The
Android NDK is also notorious for having crap implementations in their
standard libraries, so it wouldn't surprise me if ostringstream was
slow. Just use SDL_snprintf or something simpler.

- Try looking for an Android tool (DDMS?) that can measure frame rate
for you and compare your numbers to see if they are the same.

- Avoid setting SDL_RENDERER_ACCELERATED and SDL_THREAD_PRIORITY_HIGH
and try/trust the defaults. I think SDL_RENDERER_ACCELERATED is
supposed to be the default, but try ruling out a bug where the flag
makes it slower. And mucking with the thread priorities can be very
unpredictable depending on the platform's scheduler and you could be
shooting yourself in the foot with that.

- Also try ditching the SDL_WINDOW_BORDLESS and SDL_WINDOW_OPENGL.

- Try using smaller textures. If you have too high a texture
resolution, you might be getting killed in fill rate.

- Try setting the color and bit depths differently.
https://wiki.libsdl.org/SDL_GL_SetAttribute

- Maybe you should be calling SDL_PollEvent to make sure the SDL event
queue is getting cleared and not having to deal with overflow
avoidance.

- Your log printing can also overwhelm the system. You might consider
only printing every second or two and print the average in that
duration.

- Try using the SDL_PerformanceCounter instead of SDL_GetTicks. I
doubt it is going to matter here, but the former was designed for
performance measurements like you are doing here.

-Eric
_______________________________________________
SDL mailing list
[email protected]
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org