Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: too bad performance on firemonkey 10.2.1



Permlink Replies: 34 - Last Post: Nov 1, 2017 2:33 AM Last Post By: Markus Humm Threads: [ Previous | Next ]
Quang Le Hong

Posts: 6
Registered: 12/4/16
too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 2, 2017 7:20 PM
Im a big fan of delphi, until now delphi can build android/ios app
but after a lot of tries, the performance of firemonkey on android (not ios) is too bad
I dont know why, my device is note 8 but very slow, lag, glitch,choppy
Im using custom style for item in list view, and the scroll speed is unacceptabe

please help :(
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 12:19 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Am 03.10.2017 um 04:20 schrieb Quang Le Hong:
Im a big fan of delphi, until now delphi can build android/ios app
but after a lot of tries, the performance of firemonkey on android (not ios) is too bad
I dont know why, my device is note 8 but very slow, lag, glitch,choppy
Im using custom style for item in list view, and the scroll speed is unacceptabe

please help :(

Hello,

please look at sopme older posts in this newsgroup.
This is a known problem with Tokyo as they changed something in the
architecture regarding Android and failed to see the performance issues
created, since they don't seem to appear in "hello world" kind of apps.

There is already an update available reducing the issue, but this
doesn't completely fix it. A next update is according to Embarcadero in
the works already, but they don't give a precise time frame for release yet.

In these older posts there is a quality portal issue named where you can
subscribe to and for which you can vote to express that you're affected
as well. And if you find additional data regarding this you can add it.

e.g. there are certain test apps linked which you can use to gather some
performance data and you can add this data to the report so we know
how's the situation on a note 8 device.

Greetings

Markus
Quang Le Hong

Posts: 6
Registered: 12/4/16
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 1:11 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Am 03.10.2017 um 04:20 schrieb Quang Le Hong:
Im a big fan of delphi, until now delphi can build android/ios app
but after a lot of tries, the performance of firemonkey on android (not ios) is too bad
I dont know why, my device is note 8 but very slow, lag, glitch,choppy
Im using custom style for item in list view, and the scroll speed is unacceptabe

please help :(

Hello,

please look at sopme older posts in this newsgroup.
This is a known problem with Tokyo as they changed something in the
architecture regarding Android and failed to see the performance issues
created, since they don't seem to appear in "hello world" kind of apps.

There is already an update available reducing the issue, but this
doesn't completely fix it. A next update is according to Embarcadero in
the works already, but they don't give a precise time frame for release yet.

In these older posts there is a quality portal issue named where you can
subscribe to and for which you can vote to express that you're affected
as well. And if you find additional data regarding this you can add it.

e.g. there are certain test apps linked which you can use to gather some
performance data and you can add this data to the report so we know
how's the situation on a note 8 device.

Greetings

Markus

thank you, hope they will fix the android performance and keyboard overlap issue in next update
loki loki

Posts: 787
Registered: 7/1/02
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 2:37 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 12:40 PM   in response to: Quang Le Hong in response to: Quang Le Hong
Quang Le Hong wrote:

keyboard overlap issue

What's the keyboard overlap issue?

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 11:06 PM   in response to: Dave Nottage in response to: Dave Nottage
Am 03.10.2017 um 21:40 schrieb Dave Nottage (TeamB):
Quang Le Hong wrote:

keyboard overlap issue

What's the keyboard overlap issue?

Tokyo does afaik no longer report the correct coordinates for the area
covered by the keyboard. So code moving controls out of the overlapped
area will fail.

Greetings

Markus
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 4, 2017 12:18 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

What's the keyboard overlap issue?

Tokyo does afaik no longer report the correct coordinates for the area
covered by the keyboard. So code moving controls out of the overlapped
area will fail.

I figured that was what the OP meant, but was just making sure. I have a workaround for the problem if people are
interested - it requires these two units:

https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.VirtualKeyboardRect.Android.pas
https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.Messaging.pas

At the moment, it's a matter of subscribing to TVirtualKeyboardRectChangeMessage (I might change this later) which is
sent when the global layout changes, which happens after the VK shows.

The {$I} directives can safely be removed from the units if not using DW.GlobalDefines.inc

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
Quang Le Hong

Posts: 6
Registered: 12/4/16
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 4, 2017 12:25 AM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:
Markus Humm wrote:

What's the keyboard overlap issue?

Tokyo does afaik no longer report the correct coordinates for the area
covered by the keyboard. So code moving controls out of the overlapped
area will fail.

I figured that was what the OP meant, but was just making sure. I have a workaround for the problem if people are
interested - it requires these two units:

https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.VirtualKeyboardRect.Android.pas
https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.Messaging.pas

At the moment, it's a matter of subscribing to TVirtualKeyboardRectChangeMessage (I might change this later) which is
sent when the global layout changes, which happens after the VK shows.

The {$I} directives can safely be removed from the units if not using DW.GlobalDefines.inc

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com

thank you, but i still dont know why the basic thing like keyboard overlap cannot be solved by delphi itself, always required 3rd party uint :((
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 4, 2017 12:40 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Quang Le Hong wrote:

thank you, but i still dont know why the basic thing like keyboard overlap cannot be solved by delphi itself, always
required 3rd party uint :((

They can be solved, they just have not been, yet :-)

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
Pramod Nair

Posts: 105
Registered: 5/21/06
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2017 11:51 PM   in response to: Quang Le Hong in response to: Quang Le Hong
Hi Quang

I also have the same issue in the android. As you suggested i copied these 2 files to my 'uses' clause but still the keyboard overlapped the edit control. Any other changes is required please?

Quang Le Hong wrote:
Dave Nottage wrote:
Markus Humm wrote:

What's the keyboard overlap issue?

Tokyo does afaik no longer report the correct coordinates for the area
covered by the keyboard. So code moving controls out of the overlapped
area will fail.

I figured that was what the OP meant, but was just making sure. I have a workaround for the problem if people are
interested - it requires these two units:

https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.VirtualKeyboardRect.Android.pas
https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.Messaging.pas

At the moment, it's a matter of subscribing to TVirtualKeyboardRectChangeMessage (I might change this later) which is
sent when the global layout changes, which happens after the VK shows.

The {$I} directives can safely be removed from the units if not using DW.GlobalDefines.inc

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com

thank you, but i still dont know why the basic thing like keyboard overlap cannot be solved by delphi itself, always required 3rd party uint :((
Eli M

Posts: 1,346
Registered: 11/9/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 6:49 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Use Delphi Berlin for Android support.
Quang Le Hong

Posts: 6
Registered: 12/4/16
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 8:20 AM   in response to: Eli M in response to: Eli M
Eli M wrote:
Use Delphi Berlin for Android support.

I dont know why huge tools like delphi without QA/TESTING..... before releasing ???

Now moving back to old version :((
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 3, 2017 11:38 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Am 03.10.2017 um 17:20 schrieb Quang Le Hong:
Eli M wrote:
Use Delphi Berlin for Android support.

I dont know why huge tools like delphi without QA/TESTING..... before releasing ???

Now moving back to old version :((

Issue is, that this slowliness doesn't affect all Android apps.
Smaller ones with less controls on the form do not seem to be affected
too much.

But yes: QA should have identified that there's a quite visible problem!

Greetings

Markus
Eli M

Posts: 1,346
Registered: 11/9/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 4, 2017 5:07 AM   in response to: Quang Le Hong in response to: Quang Le Hong
I use other cross platform tools too and they all have similar issues. The state of development today :(
Quang Le Hong

Posts: 6
Registered: 12/4/16
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 4, 2017 9:09 AM   in response to: Eli M in response to: Eli M
Eli M wrote:
I use other cross platform tools too and they all have similar issues. The state of development today :(

have you ever use fusetools or xamarin or nativescript ???

they are cross flatform with no performance issue or keyboard overlap issue.

I still love delphi most because the drag, drop, double click too write event,...,very love the firemonkey concept,very visual and fast
Eli M

Posts: 1,346
Registered: 11/9/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 7, 2017 4:00 PM   in response to: Quang Le Hong in response to: Quang Le Hong
The HTTP client in Xamarin doesn't work for TLS 1.2. Had to be completely replaced with a third party component.
Rolf Wadewitz

Posts: 4
Registered: 11/23/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 13, 2017 6:55 AM   in response to: Eli M in response to: Eli M
Eli M wrote:
The HTTP client in Xamarin doesn't work for TLS 1.2. Had to be completely replaced with a third party component.

Moving back to Rx10.1U2 Berlin, OK.
Additionally I also have to move back to Android 6.0.1 libraries SDK and NDK android-23.

Do you have same effect, or does it work unter Beling with Android 7.0 or 7.11 android-24 ?
Eli M

Posts: 1,346
Registered: 11/9/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2017 10:50 PM   in response to: Rolf Wadewitz in response to: Rolf Wadewitz
Generally these 4 games work well under Berlin.

https://github.com/Embarcadero/DelphiArcadeGames

It was at least Android 6 and possibly 7.
Eitan Arbel

Posts: 508
Registered: 2/24/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2017 9:54 AM   in response to: Eli M in response to: Eli M
Eli M wrote:
Use Delphi Berlin for Android support.

i'm trying to use Delphi Berlin to create an Android only app, and the performance is just HORRIBLE

my simple test had 4 StringGrids on the form.
one StringGrid had 5x5 cells, all cols set for glyph.
the other 3 stringgrid had only 1 column of glyphs.
and another ListBox.

clicking the 5x5 grid worked only after about 0.5 second...

scrolling the grids took forever, and there was NO CODE behind it...

and yet, as i learned to "trust" embarcadero - they won't fix it, or maybe only in the next 10 versions...

now i'm just trying to finish what i started, and then "bye bye FireMonkey" for me...

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2017 2:55 PM   in response to: Eitan Arbel in response to: Eitan Arbel
Am 15.10.2017 um 18:54 schrieb Eitan Arbel:
Eli M wrote:
Use Delphi Berlin for Android support.

i'm trying to use Delphi Berlin to create an Android only app, and the performance is just HORRIBLE

Hello,

are you really using Berlin or rather Tokyo?
I could understand your statement if it would be Tokyo, but not really
if it was Berlin. Berlin is 10.1, Tokyo is 10.2.

Greetings

Markus
Eitan Arbel

Posts: 508
Registered: 2/24/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 28, 2017 7:40 AM   in response to: Markus Humm in response to: Markus Humm
are you really using Berlin or rather Tokyo?
Berlin is 10.1, Tokyo is 10.2.

yes, i'm sure i use Berlin... :)

as for my small project, i changed from using StringGrids with glyphs, to StringGrids with... strings...
not what i wanted, but no graphics at all, seems to work a lot better.

i just wanted to make a small game to put in Google Play Store, but as i am an intraweb programmer - IF i will (ever) use Firemonkey again, i will probably use it as a container for my intraweb application...

honestly, i feel very relieved for not needing to use FM anymore.
i wasted A LOT of time getting almost no where, and got only frustration from it...
Eli M

Posts: 1,346
Registered: 11/9/13
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2017 10:49 PM   in response to: Eitan Arbel in response to: Eitan Arbel
Generally it seems like third party grids are the way to go because they specifically tune for performance.

This one. There are others.
https://www.woll2woll.com/firepower
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 29, 2017 12:17 PM   in response to: Eli M in response to: Eli M
I find that the more controls you put on a FMX form, the more cpu it uses on OSX
any way around that?
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 6:19 AM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton Hamilton wrote:
I find that the more controls you put on a FMX form, the more cpu it uses on OSX
any way around that?

Did you try that:
https://github.com/eugenekryukov/TScene
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 10:39 AM   in response to: Ronald Klitsche in response to: Ronald Klitsche
Ronald Klitsche wrote:
Brian Hamilton Hamilton wrote:
I find that the more controls you put on a FMX form, the more cpu it uses on OSX
any way around that?

Did you try that:
https://github.com/eugenekryukov/TScene
oh, I will check it out
how do you use it though? :)
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 1:20 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton Hamilton wrote:
I find that the more controls you put on a FMX form, the more cpu it uses on OSX
any way around that?

a new FMX project, with just a whole bunch of controls on the form, and that is all (i.e no other code) uses between 10 and 17% cpu on OSX but no cpu on windows

Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 1:38 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Brian Hamilton Hamilton wrote:

a new FMX project, with just a whole bunch of controls on the form, and that is all (i.e no other code) uses between
10 and 17% cpu on OSX but no cpu on windows

My app sits around 2 - 5% when it's doing "nothing".

--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 2:05 PM   in response to: Dave Nottage in response to: Dave Nottage
My app sits around 2 - 5% when it's doing "nothing".
on what platform?
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 2:16 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
actually doing some experimenting
tmenubar
uses alot of cpu on OSX
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 30, 2017 7:36 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
actually doing some experimenting
tmenubar
uses alot of cpu on OSX

To answer your question "on what platform?": OSX

I'll check out TMenuBar.. thanks

--
Dave Nottage [TeamB]
Find hints tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 31, 2017 2:06 AM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:
actually doing some experimenting
tmenubar
uses alot of cpu on OSX

To answer your question "on what platform?": OSX

I'll check out TMenuBar.. thanks

experimenting here...a blank form with a tmenubar with say 5 items added...uses like 7 to 10% cpu (on mysetup...even a blank form is using 5 to 7% cpu)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 31, 2017 12:16 PM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Am 31.10.2017 um 10:06 schrieb Brian Hamilton Hamilton:
Dave Nottage wrote:
actually doing some experimenting
tmenubar
uses alot of cpu on OSX

To answer your question "on what platform?": OSX

I'll check out TMenuBar.. thanks

experimenting here...a blank form with a tmenubar with say 5 items added...uses like 7 to 10% cpu (on mysetup...even a blank form is using 5 to 7% cpu)

Hello,

you should report this into quality.embarcadero.com

Greetings

Markus
Brian Hamilton ...

Posts: 556
Registered: 10/14/04
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 31, 2017 6:36 PM   in response to: Markus Humm in response to: Markus Humm

Hello,

you should report this into quality.embarcadero.com

Greetings

Markus

but this is nothing new?
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 1, 2017 2:33 AM   in response to: Brian Hamilton ... in response to: Brian Hamilton ...
Am 01.11.2017 um 02:36 schrieb Brian Hamilton Hamilton:

Hello,

you should report this into quality.embarcadero.com

Greetings

Markus

but this is nothing new?

Did you check whether a rteport about this already exists or not?

Greetings

Markus
Quang Le Hong

Posts: 6
Registered: 12/4/16
Re: too bad performance on firemonkey 10.2.1
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 31, 2017 5:59 AM   in response to: Quang Le Hong in response to: Quang Le Hong
Embarcadero, please give us next big update with smooth android UI, Im still using delphi in 10 years but win32 only until now
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02