Hi all, > Am 18.04.2018 um 08:20 schrieb H. Nikolaus Schaller <h...@goldelico.com>: > > Hi Sebastian, > >> Am 17.04.2018 um 21:45 schrieb Sebastian Krzyszkowiak <d...@dosowisko.net>: >> >> On Tue, Apr 17, 2018 at 9:09 PM, H. Nikolaus Schaller <h...@goldelico.com> >> wrote: >>> >>> Am 17.04.2018 um 21:05 schrieb H. Nikolaus Schaller <h...@goldelico.com>: >>> >>> Hi Sven, >>> >>> Am 17.04.2018 um 16:31 schrieb Sven Dyroff <s.dyr...@phytec.de>: >>> >>> Hello Nikolaus, >>> >>>> It looks as if it is much more often reporting accelerometer events (ca. >>>> 15ms) than the 4.16 kernel (ca. 100-200ms). >>> >>>> But neither change has the effect of making the graphics faster and >>>> smoother. >>> >>>> So there is likely a third factor involved when comparing to GTA02. >>> >>> no, I think you've found the cause! >>> >>> 100-200ms results in a frame rate of 5 to 10 Hz which is awfully slow! >>> >>> >>> Unfortunately no. Would be too simple... >>> >>> There is a background thread that reads the accelerometer every now and then >>> and >>> simply returns the last value each time it is called. So these speeds are >>> completely >>> decoupled! QtMaze does not see any delay in code when calling getacx(). This >>> returns the value of a global variable that is updated by the background >>> thread. >>> >>> The accelerometer delay can only be recognized by a delayed reaction but >>> has no influence on the frame rate. So graphics should not have small jumps >>> if >>> you don't move the device... >>> >>> So we still have to dig deeper into it... For example someone could look >>> into the sources of QtMaze how the display redrawing is done. >>> >>> >>> It is here: >>> >>> http://git.goldelico.com/?p=gta04-qtmoko.git;a=tree;f=src/3rdparty/games/qtmaze;h=38f4df583bba2a4712baf40915bc0026fb16dc8d;hb=398d5c957571fed6b63174cfd2e4b6d57aeff9a4 >> >> From a quick glance at the code (form.cpp) is looks like the ball is >> moved only in the MoveBall method, which is called only in the >> callback from accelerometer thread (and in some other function too, >> but that function is also called only from that same callback). >> In the library, accel_work (the accelerometer thread) calls >> accelerometer_moo in a while loop until it gets a measurement and only >> then calls the QtMaze's callback, which seems to be the only way to >> actually update the ball's position. >> >> It shouldn't really work that way, and I there's a possibility that >> I'm mistaken since I just had a few minutes look into a codebase I >> never seen before, but it does really seem that by lowering the >> accelerometer read rate you'll get lowered ball movement frame rate in >> QtMaze :) > > Thanks for looking into this! > > Well, if your analysis is right, then QtMaze was developed on the > false assumption that accelerometer callbacks come in fast and well > clocked steps. > > But the kernel and the accelerometers.cpp try their best to filter > out unneeded callbacks... > > Well, I have a simple idea for a fix: remove the dependency of calling the > callback from really having received new data from the kernel. > > I.e.: > > while ( !(my_thread_data->finished) ) { > > /* Call accelerometer_moo() until we have an > acceleration measurement. */ > accelerometer_moo(accel); > > /* If the library user specified a callback, call > it. */ > if (my_thread_data->callback) > (*my_thread_data->callback)(my_thread_data->closure, > acx, acy, acz); > /* Sleep before taking another measurement. */ > usleep(my_thread_data->interval_us); > } > > So we do not call accelerometer_moo() until we have a measurement > but we call it once every interval_us. And do the callback once. > > This should then become the timer triggering a redraw and should > be almost equidistant. > > It is then the same as for the GTA02 code which calls the callback once > per loop...
Ok, this works. The ball is now moving fast like hell... IMHO too fast, but it now looks like with the GTA02 video. Same on the Pyra, but there, ball movements get completely stuck after some seconds. evtest /dev/input/accel still reports events and QtMaze still is responsive to the touchscreen, but no longer to the accelerometer. So this is some other bug... I'll now push the update to the server. Please try an apt-get upgrade in some hours (should load & install qtmoko-gta04_60.20180418-1_armhf.deb ). BR and thanks, Nikolaus > > The better solution would be to add a frame rate timer to QtMaze. > But that would be a different construction site... > > BR and thanks, > Nikolaus > > _______________________________________________ > Gta04-owner mailing list > Gta04-owner@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner _______________________________________________ Gta04-owner mailing list Gta04-owner@goldelico.com http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
