We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2816 - [patch] Android: Expose screen refresh rate
Summary: [patch] Android: Expose screen refresh rate
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: All Android (All)
: P2 enhancement
Assignee: Gabriel Jacobo
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-12 07:42 UTC by Jonas Kulla
Modified: 2015-01-23 20:58 UTC (History)
2 users (show)

See Also:

Attachments
patch (2.98 KB, patch)
2014-12-12 07:42 UTC, Jonas Kulla 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Kulla 2014-12-12 07:42:52 UTC 
Created attachment 1968 [details]
patch

Display::getRefreshRate() is available on all API levels.
Comment 1 Philipp Wiesemann 2015-01-22 22:04:02 UTC 
Thank you for providing a patch.

An idea: The new nativeSetRefreshRate() is only called close to onNativeResize(). Maybe the signature of onNativeResize() could be changed to include a parameter for the rate. Then nativeSetRefreshRate() would not be needed anymore (and the patch would be smaller :). Also the values passed to both functions are used together in Android_VideoInit() anyway. I have not tried it. Maybe I am missing something.
Comment 2 Philipp Wiesemann 2015-01-23 19:37:32 UTC 
A modified version of the patch was applied (see previous comment).
https://hg.libsdl.org/SDL/rev/8d826bc39a45

Also there seems to be a bug in some Android devices where getRefreshRate() returns a float smaller 0. For SDL_DisplayMode this does not matter because such values are shortened from float to int and therefore (being 0) just mean "unspecified" (per contract). It makes nothing worse. :)
Comment 3 Jonas Kulla 2015-01-23 20:52:32 UTC 
I consciously tried to avoid changing the signature of existing native functions because I was worried about backwards compatibility; for example, let's say I copied the native activity Java code to my project and adjusted it to my needs (etc.); if later I only upgraded the native side of SDL2, the C function would take a garbage value out of some register/stack and report that as the refresh rate.

I don't really know what your guys policy on compatibility in the Android backend and Java side is. If it is "any native side update must be accompanied by an equal Java side update", then of course your patch is fine, containing less code changes.
Comment 4 Gabriel Jacobo 2015-01-23 20:58:05 UTC 
We are eventually going to make it obvious that you are using an out of date Java file: https://bugzilla.libsdl.org/show_bug.cgi?id=2614