Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Tokyo Update 2 Android speed



Permlink Replies: 22 - Last Post: Dec 28, 2017 1:57 PM Last Post By: loki loki Threads: [ Previous | Next ]
Markus Humm

Posts: 5,113
Registered: 11/9/03
Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2017 8:40 AM
Hello,

I did some first speed tests on Android with the new Tokyo update 2.
I used the methology of this QP report:

https://quality.embarcadero.com/browse/RSP-18799

I added the new figures for the two devices I could already test on in
my big table in one of the comments (you need to expand the old
comments) and I must say: I'm pleased. It's on par with Berlin or even
slightly better in most cases. Both tested devices are low end devices
by current means.

Greetings

Markus
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2017 11:16 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Hello,

I did some first speed tests on Android with the new Tokyo update 2.
I used the methology of this QP report:

https://quality.embarcadero.com/browse/RSP-18799

I added the new figures for the two devices I could already test on in
my big table in one of the comments (you need to expand the old
comments) and I must say: I'm pleased. It's on par with Berlin or even
slightly better in most cases. Both tested devices are low end devices
by current means.

That is really great. Thanks for testing.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Robert [NL] Mit...

Posts: 100
Registered: 5/23/04
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 15, 2017 4:16 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Hello,

I did some first speed tests on Android with the new Tokyo update 2.
(...) I must say: I'm pleased. It's on par with Berlin or even
slightly better in most cases. Both tested devices are low end devices
by current means.

My first impression is also that the performance on Android has improved considerable. Good enough to release my app ro Play Store.
Of course we have to wait for the final verdict of Loki loki ;)
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 16, 2017 11:11 AM   in response to: Robert [NL] Mit... in response to: Robert [NL] Mit...
in testing here seems overall FMX optimisation has improved?
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 18, 2017 6:25 AM   in response to: Robert [NL] Mit... in response to: Robert [NL] Mit...
On 12/15/2017 3:16 PM, Robert [NL] Mittendorff wrote:
Markus Humm wrote:
Hello,

I did some first speed tests on Android with the new Tokyo update 2.
(...) I must say: I'm pleased. It's on par with Berlin or even
slightly better in most cases. Both tested devices are low end devices
by current means.

My first impression is also that the performance on Android has improved considerable. Good enough to release my app ro Play Store.
Of course we have to wait for the final verdict of Loki loki ;)

I just check it now, I think it's still just a bullsheet :(

NOTE: I just check fastly, maybe i m wrong because i need to do few fine
tuning, but my first view and test show that app made on tokyo are still
super slow compared to same app compiled on berlin.

I asked marco cantu (or anyone else working at emb) to explain clairly
where the problem was and how they solve it, but i didn't have any
answer yet, so i take a look by myself at the source code

as i read they made this :

private type
TRenderRunnable = class(TJavaLocal, JRunnable)
private class var
[weak] FManager: TWindowManager;
FMainHandler: JHandler;
private
class function GetMainHandler: JHandler; static;
public
constructor Create(const AManager: TWindowManager);
procedure run; cdecl;
class property MainHandler: JHandler read GetMainHandler;
end;
private class var
FRenderRunnable: TRenderRunnable;

instead of a timer they use in first version of tokyo :

FRenderTimer: TFmxHandle;

For information, in berlin, they was not any timer or runnable, they was
just a main loop like

while true do begin
renderIfNeed
handleTimer;
end;

now with the JRunnable the fps seam to be more accurate (around 60) and
i don't know why it's was not the case with a timer, but it's seam timer
are still slow, and if your app are slow to handle timer event, mouse
event, java event, etc.. doesn't matter that you have a 60 fps (or even
a 1000 fps) because you app will be still very slow :(

right now i compile my demo app (alfmxcontrols) with both berlin and
tokyo, and with tokyo, it's very very slow on the main page compared to
the same app compiled with berlin :(

I don't know why emb managing team don't want to revert their code to
what it's was in berlin if they are unable to making it working
correctly :( like they really want to kill delphi :(

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 18, 2017 8:03 AM   in response to: loki loki in response to: loki loki
Am 18.12.2017 um 15:25 schrieb loki loki:

[snip]

I just check it now, I think it's still just a bullsheet :(

NOTE: I just check fastly, maybe i m wrong because i need to do few fine
tuning, but my first view and test show that app made on tokyo are still
super slow compared to same app compiled on berlin.

I asked marco cantu (or anyone else working at emb) to explain clairly
where the problem was and how they solve it, but i didn't have any
answer yet, so i take a look by myself at the source code

as i read they made this :

private type
TRenderRunnable = class(TJavaLocal, JRunnable)
private class var
[weak] FManager: TWindowManager;
FMainHandler: JHandler;
private
class function GetMainHandler: JHandler; static;
public
constructor Create(const AManager: TWindowManager);
procedure run; cdecl;
class property MainHandler: JHandler read GetMainHandler;
end;
private class var
FRenderRunnable: TRenderRunnable;

instead of a timer they use in first version of tokyo :

FRenderTimer: TFmxHandle;

For information, in berlin, they was not any timer or runnable, they was
just a main loop like

while true do begin
renderIfNeed
handleTimer;
end;

now with the JRunnable the fps seam to be more accurate (around 60) and
i don't know why it's was not the case with a timer, but it's seam timer
are still slow, and if your app are slow to handle timer event, mouse
event, java event, etc.. doesn't matter that you have a 60 fps (or even
a 1000 fps) because you app will be still very slow :(

right now i compile my demo app (alfmxcontrols) with both berlin and
tokyo, and with tokyo, it's very very slow on the main page compared to
the same app compiled with berlin :(

I don't know why emb managing team don't want to revert their code to
what it's was in berlin if they are unable to making it working
correctly :( like they really want to kill delphi :(


Nom they don't want to kill it, stop writing such nonsensical claims. I
guess the new code is compatible with the plan to add platform controls
while the old one most likely isn't.

Did you check the numbers I reported in the QP report gathered youing
the demo you had provided back then?

If it's as slow as you think, how did I manage to get about the same
speed (in numbers) as with the Berlin version?

(I couldn't check my real app yet, partly due to 3rd party dependencies
and currently nott having access to that)

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 18, 2017 3:06 PM   in response to: Markus Humm in response to: Markus Humm

Nom they don't want to kill it, stop writing such nonsensical claims. I
guess the new code is compatible with the plan to add platform controls
while the old one most likely isn't.

Did you check the numbers I reported in the QP report gathered youing
the demo you had provided back then?

If it's as slow as you think, how did I manage to get about the same
speed (in numbers) as with the Berlin version?

(I couldn't check my real app yet, partly due to 3rd party dependencies
and currently nott having access to that)

Greetings

Markus

i don't think they want, but i think they do it :)

About the number, yes on the demo i did it's now good with tokyo update
2, but with another demo i have, it's still very slow. But i found why
;) it's because i have in this second demo some native controls. The
problem is that on android, moving a windows (container of native
control) is very slow. before on Berlin where they was 2 GUI thread,
it's was not a big problem if the moving of the windows take lot of time
because it's not slow down the delphi main ui thread (where we render
everything).
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 18, 2017 9:03 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

I don't know why emb managing team don't want to revert their code to
what it's was in berlin if they are unable to making it working
correctly :( like they really want to kill delphi :(

Because having two GUI threads was wrong to begin with.

Reverting to that would be exercise in futility.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 18, 2017 2:48 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
On 12/18/2017 8:03 PM, Dalija Prasnikar wrote:
loki loki wrote:

I don't know why emb managing team don't want to revert their code to
what it's was in berlin if they are unable to making it working
correctly :( like they really want to kill delphi :(

Because having two GUI threads was wrong to begin with.

Reverting to that would be exercise in futility.

Yes ... but if the Merging of the 2 threads is not working then the 2
GUI thread is not a wrong begin with ;)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 19, 2017 2:30 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
On 12/18/2017 8:03 PM, Dalija Prasnikar wrote:
loki loki wrote:

I don't know why emb managing team don't want to revert their code to
what it's was in berlin if they are unable to making it working
correctly :( like they really want to kill delphi :(

Because having two GUI threads was wrong to begin with.

Reverting to that would be exercise in futility.

Yes ... but if the Merging of the 2 threads is not working then the 2
GUI thread is not a wrong begin with ;)

Two GUI threads is architecturally wrong. It causes plethora of other problems
because it is wrong design. Maybe you are willing to sacrifice for the sake of
gaining speed, but that does not mean that everyone else should suffer.

Problems with speed are solvable, but it may take time to figure out
all possible bottlenecks and finding proper solutions for them. You can help
them and yourself by providing specific scenarios where speed is not good enough.

You have specific problems, most people don't have them. So your
definition of "working" differs from others.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 19, 2017 4:16 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Am 19.12.2017 um 11:30 schrieb Dalija Prasnikar:
loki loki wrote:

Yes ... but if the Merging of the 2 threads is not working then the 2
GUI thread is not a wrong begin with ;)

Two GUI threads is architecturally wrong. It causes plethora of other problems
because it is wrong design. Maybe you are willing to sacrifice for the sake of
gaining speed, but that does not mean that everyone else should suffer.

Problems with speed are solvable, but it may take time to figure out
all possible bottlenecks and finding proper solutions for them. You can help
them and yourself by providing specific scenarios where speed is not good enough.

You have specific problems, most people don't have them. So your
definition of "working" differs from others.

Marco also told me, that he has a blog post in preparation about the
issue. Might shed some more liggh on that matzter, as soon as it's
published. But it might take 1-2 days until publication of it.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 19, 2017 4:22 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Two GUI threads is architecturally wrong. It causes plethora of other problems
because it is wrong design. Maybe you are willing to sacrifice for the sake of
gaining speed, but that does not mean that everyone else should suffer.

yes i agree ! it's take lot of problem i don't say that 2 GUI threads is
good (i prefer to say 2 main thread).

But why it's was originally designed like this ? maybe for a good reason ;)


You have specific problems, most people don't have them. So your
definition of "working" differs from others.

I don't think problem is only connected to me, maybe i m the only one to
worry about it because many people (if not all) already stop from
developing with firemonkey ;)

today i face this problem :
https://stackoverflow.com/questions/47885038/delphi-tokyo-how-to-wait-mouse-event-from-the-main-thread

it's not only connected to me, it's connected to everyone who use
scrollbox, listbox, etc.. and everyone who want to have smooth animation
of course !
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 19, 2017 11:13 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
Two GUI threads is architecturally wrong. It causes plethora of other problems
because it is wrong design. Maybe you are willing to sacrifice for the sake of
gaining speed, but that does not mean that everyone else should suffer.

yes i agree ! it's take lot of problem i don't say that 2 GUI threads is
good (i prefer to say 2 main thread).

But why it's was originally designed like this ? maybe for a good reason ;)


You have specific problems, most people don't have them. So your
definition of "working" differs from others.

I don't think problem is only connected to me, maybe i m the only one to
worry about it because many people (if not all) already stop from
developing with firemonkey ;)

today i face this problem :
https://stackoverflow.com/questions/47885038/delphi-tokyo-how-to-wait-mouse-event-from-the-main-thread

it's not only connected to me, it's connected to everyone who use
scrollbox, listbox, etc.. and everyone who want to have smooth animation
of course !

I have no idea what your problem is. You posted some code - pretty much
out of the context - that does not work anymore, but it is completely unclear
what was original problem you are trying to solve.

Yes, I get it some issue with TAniCalculations but what it is I cannot tell.

And yes, I have tried your sample connected with speed bug report and it
works rather fine with your and standard Delphi controls on rather old
Android tablet.

Your controls are faster and if that is not good enough for you, I seriously
don't know what do you expect.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 19, 2017 4:46 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

I have no idea what your problem is. You posted some code - pretty much
out of the context - that does not work anymore, but it is completely unclear
what was original problem you are trying to solve.

i will try to make a demo. the problem i try to solve is that even if
you have a 60 fps frame rate, when you finger touch the screen you will
have some ugly "jerk" in the animation (and in opposite a quite fine
animation when your finger don't touch the screen).

This is because the "paint" must be launched every 16ms, but sometime
their is not enough gap between each paint to process (or receive) the
mouse move event, and this result in some jerk. it's because even if you
move your finger, the move event was not fired between 2 repaint and
visually the 2 repaint look like one because nothing move

to compensate this, in berlin, in the onpaint i wait max 4 ms that the
mousemove event was processed, i did like this :

while (not fMouseEventReceived) and (FPlatformTimer.getTick - T < 0.004)
do begin
EventPollValue := ALooper_pollAll(1, nil, nil,
PPointer(@PEventPollSource));
if (EventPollValue = ALOOPER_POLL_ERROR) or (EventPollValue =
ALOOPER_POLL_TIMEOUT) then continue;
if GetAndroidApp.destroyRequested &lt;&gt; 0 then continue;
if (PEventPollSource &lt;&gt; nil) and
Assigned(PEventPollSource^.process) then
PEventPollSource^.process(GetAndroidApp, PEventPollSource);
end;

but now i can't run anymore this code under tokyo :(

And yes, I have tried your sample connected with speed bug report and it
works rather fine with your and standard Delphi controls on rather old
Android tablet.

yes mine too, it's work rather fine now, it's in some other scenario
that it's not work fine. i will try to make a demo

Your controls are faster and if that is not good enough for you, I seriously
don't know what do you expect.

my control are ok, i get now with delphi tokyo update 2 a good fine 60
fps animation (except when my finger touch the screen but i work on it) :)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 20, 2017 2:53 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

I have no idea what your problem is. You posted some code - pretty much
out of the context - that does not work anymore, but it is completely unclear
what was original problem you are trying to solve.

i will try to make a demo. the problem i try to solve is that even if
you have a 60 fps frame rate, when you finger touch the screen you will
have some ugly "jerk" in the animation (and in opposite a quite fine
animation when your finger don't touch the screen).

Have you tried any native apps that do the similar thing? No matter what
you do, when GC is triggered on Android, and it is if you have to scroll large
amount of items fast (or slow), you will have ugly stops. And while iOS
handles those a bit better because it has deterministic memory management -
ARC - there are still situations when animations don't go all that well or even
crash.

Animations using regular view hierarchy are never 100% perfect. And if you are
writing a game where you need better responsiveness and smoothness then you
will use completely different architecture and rendering model.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 20, 2017 2:37 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

Have you tried any native apps that do the similar thing? No matter what
you do, when GC is triggered on Android, and it is if you have to scroll large
amount of items fast (or slow), you will have ugly stops. And while iOS
handles those a bit better because it has deterministic memory management -
ARC - there are still situations when animations don't go all that well or even
crash.

Memory management it's other thing. here i make a quite big
investigation to understand why the anim is ok when the finger is not
touching the screen, and the anim is with jerk when the finger is
touching the screen (but not always, in some case it's ok, it's depend
how much time take the Paint). i find it out that it's was because
sometime the paint is call 2 or 3 times successively before to handle
the mouse move, and as the paint take 16 ms (even if less, openGL will
make the rendering thead waiting the openGL synch signal that is fired
every 16ms)

The problem is by the way the same on iOS !

this is how i did in berlin and in iOS

{$IFDEF ANDROID}
if down and (not fMouseEventReceived) then begin
T := FPlatformTimer.getTick;
while (not fMouseEventReceived) and (FPlatformTimer.getTick - T <
0.004) do begin
EventPollValue := ALooper_pollAll(1, nil, nil,
PPointer(@PEventPollSource));
if (EventPollValue = ALOOPER_POLL_ERROR) or (EventPollValue =
ALOOPER_POLL_TIMEOUT) then continue;
if GetAndroidApp.destroyRequested <> 0 then continue;
if (PEventPollSource <> nil) and
Assigned(PEventPollSource^.process) then
PEventPollSource^.process(GetAndroidApp, PEventPollSource);
end;
end;

{$ENDIF}
{$IFDEF IOS}
// this hack to handle
https://stackoverflow.com/questions/46157947/ios-how-to-check-for-touch-event-between-2-frame-updates
// so the idea is that if the mouse is down and not yet processed
the mouse move then wait max 2 ms
if down and (not fMouseEventReceived) then begin
T := FPlatformTimer.getTick;
while (not fMouseEventReceived) and (FPlatformTimer.getTick - T <
0.004) do begin
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.001, true);
end;
end;
{$ENDIF}

fMouseEventReceived := False;


Animations using regular view hierarchy are never 100% perfect. And if you are
writing a game where you need better responsiveness and smoothness then you
will use completely different architecture and rendering model.

normally the rendering model of delphi is the typical rendering model of
games :) IE: draw everything on a custom openGL surface. so it's not
normal everything is not smooth
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 23, 2017 1:21 AM   in response to: loki loki in response to: loki loki
loki loki wrote:


Animations using regular view hierarchy are never 100% perfect. And if you are
writing a game where you need better responsiveness and smoothness then you
will use completely different architecture and rendering model.

normally the rendering model of delphi is the typical rendering model of
games :) IE: draw everything on a custom openGL surface. so it's not
normal everything is not smooth

It does not matter on which surface you render, but what is the rendering logic.

Game rendering is done with delta time passed between last rendered scene and
current rendered scene. Also games include a lot of caching. They don't redraw from
scratch every single thingy.

Game loops are not timer based. They process input, render according to
the time passed in between and then update the screen - draw on surface.

Game engines are capable to adapt to lower FPS if device is not powerful enough
You can have perfectly smooth game running with 30 FPS. The secret is in drawing
based on delta time, not in catching every single frame.

I am not saying that there are other things in Delphi app that might interfere with
your code. But it seems to me that you are chasing each and every frame and that
sounds like the wrong approach. Human eye is not capable of seeing one frame
drop. If you can see it then it is not FPS that is the culprit, but your rendering logic.

I don't have the full picture of what are you doing and how. I don't have the time
to understand your exact problem since you are usually just asking about bits and
pieces that don't actually give complete picture. But from what I got, you are trying
to make timer based animation running smoothly. You cannot. Timers are not precise
enough and they are not guaranteed to fire at exact point in time.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 23, 2017 1:58 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
I am not saying that there are other things in Delphi app that might interfere with
your code. But it seems to me that you are chasing each and every frame and that
sounds like the wrong approach. Human eye is not capable of seeing one frame
drop. If you can see it then it is not FPS that is the culprit, but your rendering logic.

You are false here :(

See this that was made by google :
https://www.youtube.com/watch?v=CaMTIgxCSqU

notice in the demo when he make suddenly a 60fps going down to 30 fps !
This what we have here

And this link to understand vsync :
https://www.youtube.com/watch?v=1iaHxmfZGGc

See when he compare the 58 fps to the 60 fps, It's exactly here he start
to speak about jank, lag, hitching

so this why we don't need 50, 55 or 58 but 60 fps ! no less !!

I don't have the full picture of what are you doing and how. I don't have the time
to understand your exact problem since you are usually just asking about bits and
pieces that don't actually give complete picture. But from what I got, you are trying
to make timer based animation running smoothly. You cannot. Timers are not precise
enough and they are not guaranteed to fire at exact point in time.

No timer at all! and as far as i know in delphi tokyo update 2 their in
not anymore any "timer".

You must probably understand that with openGL their is no concept of
timer, with openGL you have what we call a "vsynch" signal. to resume,
you say now redraw everything and it's openGL that will freeze you main
thread waiting the vsynsh signal (every 16 ms) to swap the surface.

the problem i face is that delphi is badly designed because it's gave to
input event something like a low priority :( but if you don't receive
the mouse move event, it's look like a jerk because the screen position
is not updated
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 23, 2017 3:54 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
I am not saying that there are other things in Delphi app that might interfere with
your code. But it seems to me that you are chasing each and every frame and that
sounds like the wrong approach. Human eye is not capable of seeing one frame
drop. If you can see it then it is not FPS that is the culprit, but your rendering logic.

You are false here :(

I am not.

See this that was made by google :
https://www.youtube.com/watch?v=CaMTIgxCSqU

notice in the demo when he make suddenly a 60fps going down to 30 fps !
This what we have here

And this link to understand vsync :
https://www.youtube.com/watch?v=1iaHxmfZGGc

See when he compare the 58 fps to the 60 fps, It's exactly here he start
to speak about jank, lag, hitching

so this why we don't need 50, 55 or 58 but 60 fps ! no less !!

That is something completely different. I am talking about algorithms
involved to draw frames that differs between games and general app
UI.

https://quality.embarcadero.com/browse/RSP-19022

Game rendering algorithms are completely different from general UI
algorithms.

Game rendering happens based on time difference and such algorithms
are more tolerable to frame drops, because they adapt to actual FPS and
don't try to draw each and every frame.

In above report you are talking about missing OnPaint events. OnPaint events
draw each change, they are not exactly designed to drop frames if they cannot
draw fast enough or if changes happen too fast.

You don't need 60 FPS to have smooth experience, you just need better drawing
algorithms. Yes, with more FPS you can get better results, but that does not mean
you cannot achieve smooth scrolling at 30 FPS.

Problem is that games are designed to handle lower FPS rates, general App UI
works on different premises and cannot catch up at times. This is not Delphi specific
issue.


I don't have the full picture of what are you doing and how. I don't have the time
to understand your exact problem since you are usually just asking about bits and
pieces that don't actually give complete picture. But from what I got, you are trying
to make timer based animation running smoothly. You cannot. Timers are not precise
enough and they are not guaranteed to fire at exact point in time.

No timer at all! and as far as i know in delphi tokyo update 2 their in
not anymore any "timer".

You must probably understand that with openGL their is no concept of
timer, with openGL you have what we call a "vsynch" signal. to resume,
you say now redraw everything and it's openGL that will freeze you main
thread waiting the vsynsh signal (every 16 ms) to swap the surface.

the problem i face is that delphi is badly designed because it's gave to
input event something like a low priority :( but if you don't receive
the mouse move event, it's look like a jerk because the screen position
is not updated

Maybe I confused you with someone else talking about timers. I know how
vsync works. Again, problem is in rendering algorithm that.

I don't have solution to your problem - if there is a problem, because I cannot
see any problem using your Demo compiled on Tokyo. Scrolling is never perfect
and I am not talking about Delphi here.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 28, 2017 5:28 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
You don't need 60 FPS to have smooth experience, you just need better drawing
algorithms. Yes, with more FPS you can get better results, but that does not mean
you cannot achieve smooth scrolling at 30 FPS.

sorry, for video yes it's acceptable to have 30fps, but for scrolling
box with text and image, definitively you can't have anything serious at
30 fps. or we don't have the same definition of smooth experience ;)

Problem is that games are designed to handle lower FPS rates, general App UI
works on different premises and cannot catch up at times. This is not Delphi specific
issue.

It's not (really) about the algorithm that game differs from Delphi,
it's simply that game look visually more like video and for such
animation, 30 fps it's ok.

Anyways, in any tutorial/doc/everything regarding programing UI
interface, they always strongly advice about 60fps without frame drop !
and in next release of ios, they will even now go to 120 fps !!
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 28, 2017 6:15 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
You don't need 60 FPS to have smooth experience, you just need better drawing
algorithms. Yes, with more FPS you can get better results, but that does not mean
you cannot achieve smooth scrolling at 30 FPS.

sorry, for video yes it's acceptable to have 30fps, but for scrolling
box with text and image, definitively you can't have anything serious at
30 fps. or we don't have the same definition of smooth experience ;)

Problem is that games are designed to handle lower FPS rates, general App UI
works on different premises and cannot catch up at times. This is not Delphi specific
issue.

It's not (really) about the algorithm that game differs from Delphi,
it's simply that game look visually more like video and for such
animation, 30 fps it's ok.

Anyways, in any tutorial/doc/everything regarding programing UI
interface, they always strongly advice about 60fps without frame drop !
and in next release of ios, they will even now go to 120 fps !!

Of course, Apple will do that. They have to sell you new hardware.

Without going into discussion about algorithms and how screen looks in
video game and normal UI, point is achieving smooth scrolling is
mission impossible.

To make things clear, yes faster and smoother is better and there is still
room to optimize things in Delphi. But it is not something urgent that must
be done overnight. What I am trying to say, is that users don't care about
the difference you talk about. Yes, if I look carefully I can spot the difference
between your controls and Delphi ones, but that difference is not important
when I am using the application as user.

Also, even native tools are not capable of achieving such smooth
scrolling you desire. As long as user can put finger on the screen and you
can scroll content without causing visible delay in feedback you have properly
functioning application.

Again, even Delphi native controls (that are slower than yours) provide quite
satisfying user experience.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 28, 2017 1:57 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Without going into discussion about algorithms and how screen looks in
video game and normal UI, point is achieving smooth scrolling is
mission impossible.

I just want to add a link that show very well the difference between
24fps and 60fps:
https://www.youtube.com/watch?v=WyvUIA7KUjc


To make things clear, yes faster and smoother is better and there is still
room to optimize things in Delphi. But it is not something urgent that must
be done overnight. What I am trying to say, is that users don't care about
the difference you talk about. Yes, if I look carefully I can spot the difference
between your controls and Delphi ones, but that difference is not important
when I am using the application as user.

depend of the application :) ... if you are doing b2b app, maybe not,
but if you are doing instagram like app surelly yes ;) if you want i can
send you in private the link to my app (and a link to another similar
app done in delphi with traditional delphi control) you will judge by
yourself ...


Again, even Delphi native controls (that are slower than yours) provide quite
satisfying user experience.

depend of the type of app and kind of user your are targeting
Richard Stevens

Posts: 52
Registered: 5/1/00
Re: Tokyo Update 2 Android speed
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 15, 2017 6:56 AM   in response to: Markus Humm in response to: Markus Humm
Thank you very much for testing and passing this on, that's good news.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02