Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: Tokyo update release 2 => worse than ever :(



Permlink Replies: 38 - Last Post: Jan 13, 2018 4:03 AM Last Post By: loki loki
loki loki

Posts: 787
Registered: 7/1/02
Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 2:08 AM
I try tokyo update 2, thinking most of the problems of the first release
of tokyo under android was corrected. Need to say i m fully disappointed :(

4 days i try to make an app that work perfectly on berlin working with
tokyo :( without any success !

many bug in the firemonkey, and some exception are very hard to catch,
like now when i realign controls i have invalid float operation
exception (because their size look like NAN, don't know how it's possible)

For the few think :

1/ merging of the Android/delphi UI thread result in app much more slow,
even in update 2
2/ app made in tokyo seam to use 2x more memory than same app compiled
in berlin
3/ multithreading bitmap are not working at all (was not even tested by
the emb team i guess)
4/ bug bug bug everywhere, can't compile in tokyo my previous app made
in berlin. worse i have sometime some strange exception, compile again
the app and the exception dispear :( this is scary !!

when i read
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/10.2_Tokyo_-_Release_2
half of the article is about

FireMonkey Quick Edit
New VCL Controls
Updated IDE Look & Feel
Installer Enhancements

serious they have nothing more important to do ??????

I start to think that it's a pure sabotage ! i can't believe that the
emb team could be so bad (or say so stupid) do to think like this !

Bob Carson

Posts: 62
Registered: 10/8/04
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:00 AM   in response to: loki loki in response to: loki loki
I'm sorry to hear the latest update of Tokyo has not solved important problems with your work. I have recompiled and tested nearly all my apps for Windows, Macintosh, Android and iOS, and I can honestly say everything is working better than ever before. Especially the apps running on Macintosh. The only thing that was not fixed is an Access Violation or protection fault when trying to GetSongs under iOS. This still works on Android. Try the sample that gets and plays songs. Apps available at: www.accessoryware.com. Without FireMonkey, I never could have done what is available on my web site.
Pasquale Esposito

Posts: 50
Registered: 6/5/13
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:10 AM   in response to: Bob Carson in response to: Bob Carson
Bob Carson wrote:
I'm sorry to hear the latest update of Tokyo has not solved important problems with your work. I have recompiled and tested nearly all my apps for Windows, Macintosh, Android and iOS, and I can honestly say everything is working better than ever before. Especially the apps running on Macintosh. The only thing that was not fixed is an Access Violation or protection fault when trying to GetSongs under iOS. This still works on Android. Try the sample that gets and plays songs. Apps available at: www.accessoryware.com. Without FireMonkey, I never could have done what is available on my web site.

Does the latest Tokyo update allow you to compile 64-bit apps for macOS?
Ken Randall

Posts: 130
Registered: 11/12/99
Re: Tokyo update release 2 => worse than ever :( [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:35 AM   in response to: Pasquale Esposito in response to: Pasquale Esposito
Does the latest Tokyo update allow you to compile 64-bit apps for
macOS?

No it doesn't but I didn't think it was scheduled for this version!
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :( [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 7:09 AM   in response to: Ken Randall in response to: Ken Randall
Am 31.12.2017 um 15:35 schrieb Ken Randall:
Does the latest Tokyo update allow you to compile 64-bit apps for
macOS?

No it doesn't but I didn't think it was scheduled for this version!

indeed it wasn't.
Is there any recording of that roadmap webinar they held shortly before
Christmas? I had to miss it due to being a bit sick at that time.

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tokyo update release 2 => worse than ever :( [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 4:53 PM   in response to: Pasquale Esposito in response to: Pasquale Esposito
Pasquale Esposito wrote:

Does the latest Tokyo update allow you to compile 64-bit apps for
macOS?

No. That was not one of the advertised new features anyway.

--
Rudy Velthuis http://www.rvelthuis.de

"Strange is our situation here upon Earth."
-- Albert Einstein
Pasquale Esposito

Posts: 50
Registered: 6/5/13
Re: Tokyo update release 2 => worse than ever :( [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 11:41 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
Pasquale Esposito wrote:

Does the latest Tokyo update allow you to compile 64-bit apps for
macOS?

No. That was not one of the advertised new features anyway.

--
Rudy Velthuis http://www.rvelthuis.de

"Strange is our situation here upon Earth."
-- Albert Einstein

It's a shame. I'm sure you all know that, as of today, you are prevented from submitting any new macOS app developed in FireMonkey to the App Store.
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:42 AM   in response to: loki loki in response to: loki loki
Hello everyone.

I partially agree with @loki loki.

When we develop perfect applications with many details, nothing can fail primarily usability.

@Bob Carson
Unfortunately your app was not well tested :(
It is super slow and still produces errors

https://ibb.co/nDTaXG

https://imgur.com/a/b6lHY

https://www.photobox.co.uk/my/photo?album_id=5205524837&photo_id=500444413556

There are several details that @embarcadero needs to improve.
But you have to understand that most countries are financial capitalists and they always need to release new versions of their products to get cash.

I was very sad for not having an FMX version for Linux32.
I wonder do you guys think x86 or any 32 bit architecture will die by 2030?

When will x128 be released?

@Embarcadero does not like those words @loki loki
http://blog.marcocantu.com/blog/2018-08-qualityportal_tokyoR1.html
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 8:18 AM   in response to: wesley bobato in response to: wesley bobato
There are several details that @embarcadero needs to improve.
But you have to understand that most countries are financial capitalists and they always need to release new versions of their products to get cash.

This i understand, but their is a world between new version and new
piece of sh##t :) New version, with even few improvement that work well
it's 10000000% better than new version with lot of improvement that not
work at all and make everything unstable !
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 8:45 AM   in response to: loki loki in response to: loki loki
Hello @loki loki.

we understand your dissatisfaction.
but it's impossible to clearly understand what really matters in your software if you do not share anything.

you just express your feelings.
for everyone to understand clearly we need to see code or a video.

It shows the world what happens when you are using your software.
I'm sure a lot of people can help you.

Create a complete report and send it to @marco cantu.
express the minimum details, create a video with berlin vs tokyo.

many people here are willing to help you, but you need to share code or video for people to understand this feeling of frustration.

we know that you are a genius, but remember we can always learn more and exchange new experiences.

the firemonkey creator posted this.
https://github.com/eugenekryukov/TScene

TScene
Isolated buffered container control for FireMonkey.

FireMonkey Drawing Model
FireMonkey drawing model is different from classic UI model used for example on Windows. FM doesn't have own canvas for each control. Canvas is shared between all children controls of the form.

The main goal of this model is supporting composition and semi-transparency controls. But disadvantage of it is processing whole tree of controls in every frame. On desktop platform FM quite optimised to use updating regions, but it is still requires to process whole tree.

TScene drawing model
TScene is a TControl descendant which incapsulated IScene interface and provide isolated drawing of his children. Internally it has buffer where all children controls paint.

When TScene paints to the form canvas it paints his buffer only. If children control want to be updated, TScene paints this control to own buffer and keep it unmodified to next update requiest.

Using of TScene allows dramatically improve drawing performance of complicated controls tree or complcated control (for example group of TPath or big image).

TScene break FM drawing model, which means when form paints all his children it stops on TScene and doesn't process TScene's children controls.

nobody knows here if you use TmyThread = class (TThread)
or TThread.CreateAnonymousThread or TTimer or TTask and etc.

Contact www.ksdev.com Talk to the firemonkey creator he can help you.
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 9:09 AM   in response to: wesley bobato in response to: wesley bobato
we understand your dissatisfaction.
but it's impossible to clearly understand what really matters in your software if you do not share anything.

you just express your feelings.
for everyone to understand clearly we need to see code or a video.

It shows the world what happens when you are using your software.
I'm sure a lot of people can help you.

Create a complete report and send it to @marco cantu.
express the minimum details, create a video with berlin vs tokyo.

Baah like i say in previous post, emb say that a key feature of tokyo is
that now bitmap are multithread. well today with the release of update 2
of tokyo, i decide to test this key feature. Exactly 5 min after start
to testing it, i see that bitmap are absolutely not working in
multithread ! i say 5 min ! so how they test what their are doing ?

I make a fast demo of the bug here:
https://quality.embarcadero.com/browse/RSP-19673

demo was easy to do, just use bitmap in multithread ;) so seriously you
understand why i m unhappy, it's because they don't test anything !

like releasing tokyo without seeing that now all android app will be 2x
more slower! how possible they didn't see it ????

this is a very serious problem (not the bug, the fact they didn't test
what they are doing)


TScene
Isolated buffered container control for FireMonkey.

Bof, i prefer my double-buffered control than an Isolated buffered
container :) someone already did this (Isolated buffered container) many
years ago with XE5, it's didn't really work ... control must interact
each other, and have a fix picture of them break this

FireMonkey Drawing Model
FireMonkey drawing model is different from classic UI model used for example on Windows. FM doesn't have own canvas for each control. Canvas is shared between all children controls of the form.

yes, and this is not a big problem ..

The main goal of this model is supporting composition and semi-transparency controls. But disadvantage of it is processing whole tree of controls in every frame. On desktop platform FM quite optimised to use updating regions, but it is still requires to process whole tree.

yes exactly, but it's logical :) nothing surprise me here ... this why i
created double-buffered control, to not redraw and redraw each control
on each paint (just redraw their internal picture)


TScene drawing model
TScene is a TControl descendant which incapsulated IScene interface and provide isolated drawing of his children. Internally it has buffer where all children controls paint.

When TScene paints to the form canvas it paints his buffer only. If children control want to be updated, TScene paints this control to own buffer and keep it unmodified to next update requiest.

Using of TScene allows dramatically improve drawing performance of complicated controls tree or complcated control (for example group of TPath or big image).

TScene break FM drawing model, which means when form paints all his children it stops on TScene and doesn't process TScene's children controls.

i m absolutely not fan of this approach :( I think it's much more easy
to double buffered each control to speed up drastically their paint
process. in this way nothing is break (as opposite with TScene) and you
work like before. it's just use a little more memory for the buffer
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 10:00 AM   in response to: loki loki in response to: loki loki
Hello.

When I see this topic
https://quality.embarcadero.com/browse/RSP-17162

I wonder is that this attached file was enough for the embarcadero to understand clearly.

I doubt your software will do just that which you demonstrate in this demo.
so it is very difficult to understand what is really happening in your projects.

perhaps double buffering is a problem for simple mobile phones with low ram memory.

sincerely it is impossible to help you.
when I posted earlier I told you to demonstrate what is happening in your real app.

on what pages can we download a demo to install to help you?
perhaps with some feedback we can understand with clarity and assist the embarcadero with more objective answers.

I will not come back today I will spend the rest of the day with my family.
Happy New Year, a lot of health and good luck.

My family will pray for your problems.

Edited by: wesley bobato on Dec 31, 2017 10:01 AM
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:18 AM   in response to: loki loki in response to: loki loki
Am 31.12.2017 um 18:09 schrieb loki loki:

like releasing tokyo without seeing that now all android app will be 2x
more slower! how possible they didn't see it ????

Thing is, that this one doesn't happen in all Android projects,
especially not in smaller ones with not so many controls on a form.

It should have been detected before release, yes, but in this case
whether you notice it it depends on how you test it.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 2:04 AM   in response to: Markus Humm in response to: Markus Humm

Thing is, that this one doesn't happen in all Android projects,
especially not in smaller ones with not so many controls on a form.

It should have been detected before release, yes, but in this case
whether you notice it it depends on how you test it.

Markus, sorry if i was in the delphi team, and i change the way the
paint is handled (ie: instead of doing a loop like while true do ...
paint ... end; I m doing an event based paint) then i promise you i will
at least test if the calling of paint is still at 16ms !!! else i must
change my job ...
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 4:55 PM   in response to: wesley bobato in response to: wesley bobato
wesley bobato wrote:

we know that you are a genius, but remember we can always learn more
and exchange new experiences.

Yes, please share that genius with us. <g>

--
Rudy Velthuis http://www.rvelthuis.de

"Support your local Search and Rescue unit -- get lost."
-- Unknown
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:20 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 01.01.2018 um 01:55 schrieb Rudy Velthuis (TeamB, MVP):
wesley bobato wrote:

we know that you are a genius, but remember we can always learn more
and exchange new experiences.

Yes, please share that genius with us. <g>

He already does, but publishing his Alcinoe controls (afaik on Github).

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 2:29 AM   in response to: Markus Humm in response to: Markus Humm
On 1/1/2018 12:20 PM, Markus Humm wrote:
Am 01.01.2018 um 01:55 schrieb Rudy Velthuis (TeamB, MVP):
wesley bobato wrote:

we know that you are a genius, but remember we can always learn more
and exchange new experiences.
Yes, please share that genius with us. <g>
He already does, but publishing his Alcinoe controls (afaik on Github).

Greetings

Markus

Thanks markus! what i learn nowadays is that developing is not anymore
question about being genius, it's just question about following good
programing rules and about time ! yes it's unbelievable how everything
take time ! if you have time you can do everything ...

this why i m always criticizing emb ! because when they do something new
it often cost me (us) time ! The last furious example is the new linux
compiler introduced in tokyo: they do that we can now compile under
linux that is very great, especially for my isapi IIS dll that need
windows to run. BUT in the surely not genius mind of the emb managing
team they decide to go in ARC ! making that is quite impossible to move
like this my existing code to linux (i calculate it's will cost me
months of debugging) and also making their choice quite illogical when
under linux it's only server app that are allergic to ARC !

Also releasing new version of delphi that are not well tested is
unacceptable because i lost days to debug my app to finally discover
that they simply didn't do their job fully :( this make me very furious,
i m rip off of my time and of my money :(
https://www.embarcadero.com/fr/app-development-tools-store/rad-studio
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 8:44 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

BUT in the surely not genius mind of the emb
managing team they decide to go in ARC !

Oh, another unsollicited anti-ARC rant. Should I start posting about
the evil of FreeAndNil now? <g>

--
Rudy Velthuis http://www.rvelthuis.de

"It's dangerous to underestimate the intelligence of a customer
who grew a business that's successful enough to require a large
and complex set of software" -- Grady Booch
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 11:01 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
On 1/3/2018 7:44 PM, Rudy Velthuis (TeamB, MVP) wrote:
loki loki wrote:

BUT in the surely not genius mind of the emb
managing team they decide to go in ARC !

Oh, another unsollicited anti-ARC rant. Should I start posting about
the evil of FreeAndNil now? <g>

ahah of course rant will be never solicited :) ARC was also unsolicited
!!! or solicited by people who don't really do something with delphi ahah :)
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 8:42 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 01.01.2018 um 01:55 schrieb Rudy Velthuis (TeamB, MVP):
wesley bobato wrote:

we know that you are a genius, but remember we can always learn
more >> and exchange new experiences.

Yes, please share that genius with us. <g>

He already does, but publishing his Alcinoe controls (afaik on
Github).

Seems to be on SourceForge.

But when I read the wiki, I see that one of the first sentences is
already FUD: "Unfortunatly, in win64 we lost all the FastCode
heritage." That is not true. Since XE4 (or a version nearby), there is
a lot of new FastCode code.

See here: https://stackoverflow.com/a/11261232/95954 --> Update

--
Rudy Velthuis http://www.rvelthuis.de

"When I told the people of Northern Ireland that I was an
atheist, a woman in the audience stood up and said, 'Yes, but
is it the God of the Catholics or the God of the Protestants
in whom you don't believe?" -- Quentin Crisp.
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 10:55 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...

But when I read the wiki, I see that one of the first sentences is
already FUD: "Unfortunatly, in win64 we lost all the FastCode
heritage." That is not true. Since XE4 (or a version nearby), there is
a lot of new FastCode code.

See here: https://stackoverflow.com/a/11261232/95954 --> Update

This was wrote many years ago at the time emb stupidly decide to move
string to 16 bit! Anyway even in closest version of delphi, Win64 most
of the time simply use pascal code and not dedicated optimized win64 asm
code ! I was true many years ago and still true :)
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 11:00 AM   in response to: loki loki in response to: loki loki

This was wrote many years ago at the time emb stupidly decide to move
string to 16 bit! Anyway even in closest version of delphi, Win64 most
of the time simply use pascal code and not dedicated optimized win64 asm
code ! I was true many years ago and still true :)

and to finish in demo\ALStringBenchmark\ you have 2 exe, one compiled in
32 bit and another compiled in 64 bit; you can see that the 64 bit are
often 2x more slow then their 32 bit equivalent (like strtofloat for
exemple)
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 11:03 AM   in response to: loki loki in response to: loki loki
On 1/3/2018 10:00 PM, loki loki wrote:

This was wrote many years ago at the time emb stupidly decide to move
string to 16 bit! Anyway even in closest version of delphi, Win64 most
of the time simply use pascal code and not dedicated optimized win64 asm
code ! I was true many years ago and still true :)

and to finish in demo\ALStringBenchmark\ you have 2 exe, one compiled in
32 bit and another compiled in 64 bit; you can see that the 64 bit are
often 2x more slow then their 32 bit equivalent (like strtofloat for
exemple)

and compiled with the last version of delphi (tokyo) of course ...
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 11:37 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

This was wrote many years ago at the time emb stupidly decide to move
string to 16 bit! Anyway even in closest version of delphi, Win64 most
of the time simply use pascal code and not dedicated optimized win64 asm
code ! I was true many years ago and still true :)

and to finish in demo\ALStringBenchmark\ you have 2 exe, one compiled in
32 bit and another compiled in 64 bit; you can see that the 64 bit are
often 2x more slow then their 32 bit equivalent (like strtofloat for
exemple)

Slow or not, that has nothing to do with whether or not strings are now 16bit,
but the fact 64bit code requires different assembler code than 32bit.

--
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 release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 1:59 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

Slow or not, that has nothing to do with whether or not strings are now 16bit,
but the fact 64bit code requires different assembler code than 32bit.

no it's was not connected to 16 or 8 bit string ... but i use string
function to compare because most string function use fastcode
internally. and yes speed regarding 16bity or 8bit string will be the
same (but not the memory)
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2018 4:03 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
But when I read the wiki, I see that one of the first sentences is
already FUD: "Unfortunatly, in win64 we lost all the FastCode
heritage." That is not true. Since XE4 (or a version nearby), there is
a lot of new FastCode code.

See here: https://stackoverflow.com/a/11261232/95954 --> Update

By the way can you point me at least one fastcode function that was translated to win64 ??
Or one function written in pure pascal that is more faster than the ASM fastcode equivalent ?

close to all delphi string function are from 2x to 10x more slow in win64! and this is still true in delphi tokyo ...

This is very (very) problematic for Web server app that work mainly on string function

IF i do FUD, you you do disinformation ;)

But as you seam to be a great fan of ARC, it's evident that you don't care for the speed and don't care of building server app ! you just like publisher ;)
Bob Carson

Posts: 62
Registered: 10/8/04
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 11:46 AM   in response to: wesley bobato in response to: wesley bobato
You are right. I don't spend nearly enough effort testing. The version on my site showing errors has the creation date of 2015. Long before Tokyo. I recompiled and replaced with Tokyo 10.2.2. It still loads way too slow.
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:22 PM   in response to: Bob Carson in response to: Bob Carson
Hello.

Fortunately, it's not 100% your fault.
When we use Direct2D with FMX it's super slow

I've created a similar example to your software.
https://quality.embarcadero.com/browse/RSP-19606

Please compare the performance difference in Direct2D
but GPUCanvas is super fast but it has several problems in big projects.

The problem is not always the programmer sometimes the embarcadero, does not perform stress tests with FMX.

I can find a 100 problems is super easy just to develop an example of stress that leaves the FMX crazy will stop everything.

Please test the example and share your opinions.
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:27 PM   in response to: Bob Carson in response to: Bob Carson
Hello.

Fortunately, it's not 100% your fault.
When we use Direct2D with FMX it's super slow

I've created a similar example to your software.
https://quality.embarcadero.com/browse/RSP-19606

Please compare the performance difference in Direct2D
but GPUCanvas is super fast but it has several problems in big projects.

The problem is not always the programmer sometimes the embarcadero, does not perform stress tests with FMX.

I can find a 100 problems is super easy just to develop an example of stress that leaves the FMX crazy will stop everything.

Please test the example and share your opinions.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 7:08 AM   in response to: loki loki in response to: loki loki
Am 31.12.2017 um 11:08 schrieb loki loki:
I try tokyo update 2, thinking most of the problems of the first release
of tokyo under android was corrected. Need to say i m fully disappointed :(

4 days i try to make an app that work perfectly on berlin working with
tokyo :( without any success !

many bug in the firemonkey, and some exception are very hard to catch,
like now when i realign controls i have invalid float operation
exception (because their size look like NAN, don't know how it's possible)

For the few think :

1/ merging of the Android/delphi UI thread result in app much more slow,
even in update 2
2/ app made in tokyo seam to use 2x more memory than same app compiled
in berlin
3/ multithreading bitmap are not working at all (was not even tested by
the emb team i guess)
4/ bug bug bug everywhere, can't compile in tokyo my previous app made
in berlin. worse i have sometime some strange exception, compile again
the app and the exception dispear :( this is scary !!

when i read
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/10.2_Tokyo_-_Release_2
half of the article is about

FireMonkey Quick Edit
New VCL Controls
Updated IDE Look & Feel
Installer Enhancements

serious they have nothing more important to do ??????

I start to think that it's a pure sabotage ! i can't believe that the
emb team could be so bad (or say so stupid) do to think like this !


Hello,

while I can fully understand your frustration (I had hoped to be able to
move some project from Berlin to Tokyo to get some backspace key fixes),
it doesn't help to rant about it here.

You should formulate a "well crafted" and polite but inquiring e-mail to
Marco Cantu, so he is made "officially" aware of the situation. Do
express your concerns about quality ensurance/about internal processes
at Embarcadero and how it affects quality and about adding new features
seen as minor ones (especially like quick edits, I'd personally had
found designer guides [those helpful lines from VCL form designer] more
helpful in the FMX designer...) when at the same time a lot of the
quality issues on the Android side still seem to be in the product or
new ones (like the animation issue) have crept in.

That would be of help! You may, if you want to CC that mail to Sarina
and David Millington as well.

Best regards

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 8:45 AM   in response to: Markus Humm in response to: Markus Humm
Hello,

while I can fully understand your frustration (I had hoped to be able to
move some project from Berlin to Tokyo to get some backspace key fixes),
it doesn't help to rant about it here.

Where to rant ? I invest a lot with delphi (and my reputation), but i
don't invest in a "product", I invest in a "team", (the team who build
delphi)! With tokyo i realize that i was rip off ! this team is mostly
doing "publisher" presentation, they don't even test what they have done
(it's unbelievable), letting customers doing it !!

Can i **** off with emb ? i really really would like to be able, but
changing the technology (and my own team) is something very hard and
hazardous! rebuild from scratch everything that was done is really a
pain choice :(

You should formulate a "well crafted" and polite but inquiring e-mail to
Marco Cantu, so he is made "officially" aware of the situation.
Do express your concerns about quality ensurance/about internal processes
at Embarcadero and how it affects quality and about adding new features
seen as minor ones (especially like quick edits, I'd personally had
found designer guides [those helpful lines from VCL form designer] more
helpful in the FMX designer...) when at the same time a lot of the
quality issues on the Android side still seem to be in the product or
new ones (like the animation issue) have crept in.

That would be of help! You may, if you want to CC that mail to Sarina
and David Millington as well.

hmmm, ok i will formulate politely this email :

Please marco, Sarina and David, could you (please) before to release a
new version of delphi at least TEST IT !? Could you please stop to add
new functionalities that don't work and instead focus on the quality of
what you already did (and i promise you, your client will be happy to
pay new version with only this)? Could you make for example ARC as an
option for mobile and desktop development ? maybe you could also make a
"traineeship" in a company like mine who try (desperately) to build
mobile app with delphi, you will be off course welcome :)

you really think it's will help ?? not sure they will agree to apply for
the position of "traineeship" :)

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:23 AM   in response to: loki loki in response to: loki loki
Am 31.12.2017 um 17:45 schrieb loki loki:
Hello,

hmmm, ok i will formulate politely this email :

Please marco, Sarina and David, could you (please) before to release a
new version of delphi at least TEST IT !? Could you please stop to add
new functionalities that don't work and instead focus on the quality of
what you already did (and i promise you, your client will be happy to
pay new version with only this)? Could you make for example ARC as an
option for mobile and desktop development ? maybe you could also make a
"traineeship" in a company like mine who try (desperately) to build
mobile app with delphi, you will be off course welcome :)

That direction would be a bit better, but that's still not what I'd
like, as it doesn't go into technical details and as it requests ARC to
be optional, which is something they will not do and is something which
has nothing really to do with your (our) quality problems at hand!

Please do not mix such things, it only weakens you position.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 2:43 AM   in response to: Markus Humm in response to: Markus Humm
That direction would be a bit better, but that's still not what I'd
like, as it doesn't go into technical details and as it requests ARC to
be optional, which is something they will not do and is something which
has nothing really to do with your (our) quality problems at hand!

i opposite i think ARC have a bit to do with my problem ;) because they
need to take care of ARC, they spend many time on it (because they must
keep an illness logic of arc under desktop and non arc under mobile),
and after they don't have time just to check that the painting is still
at 16ms gap under android opengl ;) everything is just question of time,
and personally i prefer they focus their time on something really
important than ARC :( i guess their is not 1000 developpers in the emb
delphi team, but they have big eyes and little stomach :(
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 4:59 AM   in response to: loki loki in response to: loki loki
Am 01.01.2018 um 11:43 schrieb loki loki:
That direction would be a bit better, but that's still not what I'd
like, as it doesn't go into technical details and as it requests ARC to
be optional, which is something they will not do and is something which
has nothing really to do with your (our) quality problems at hand!

i opposite i think ARC have a bit to do with my problem ;) because they
need to take care of ARC, they spend many time on it (because they must
keep an illness logic of arc under desktop and non arc under mobile),
and after they don't have time just to check that the painting is still
at 16ms gap under android opengl ;) everything is just question of time,
and personally i prefer they focus their time on something really
important than ARC :( i guess their is not 1000 developpers in the emb
delphi team, but they have big eyes and little stomach :(

No, in quite a lot of scenarious you can continue progamming like you
did for manual memory management.

And if ARC is so bad Apple wouldn't have introduced it on their platform
I guess. No, the issue is more likely Idera and the exchange of
programming teams (if I'm not mistaken). means: new persons making new
failures as they don't know enough about the architecture etc. yet.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 7:32 AM   in response to: Markus Humm in response to: Markus Humm
And if ARC is so bad Apple wouldn't have introduced it on their platform
I guess.
don't take apple as an example :( if you speak about marketing, yes, but
if you speak about programing don't take them at all as an example ;)
apple don't care about anything except them, it's why now you can't
deploy anymore your delphi app on OSX.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 8:42 AM   in response to: loki loki in response to: loki loki
Am 01.01.2018 um 16:32 schrieb loki loki:
And if ARC is so bad Apple wouldn't have introduced it on their platform
I guess.
don't take apple as an example :( if you speak about marketing, yes, but
if you speak about programing don't take them at all as an example ;)
apple don't care about anything except them, it's why now you can't
deploy anymore your delphi app on OSX.

I don't like Apple either, but that thing has nothing to do with ARC.
And afaik this only affects the app store as of now.

Greetings

Markus
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:10 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

And afaik this only affects

new 32-bit OSX apps on

the app store as of now.

(i.e. existing apps are not affected)

Fixed it for you ;-)

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

Posts: 91
Registered: 1/5/15
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 12:41 PM   in response to: loki loki in response to: loki loki
In my case I am happy with 10.2.2

Android start of my "main" app is 50% faster in Android. What it is important, because it was quite slow. Some crashes during start has dissapear.

I see better performance in general. It is a quite complex app that I am offering for Android, Windows and iOS.

Now I am planning to offer it in OSX.
Ken Randall

Posts: 130
Registered: 11/12/99
Re: Tokyo update release 2 => worse than ever :(
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 2:01 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

I try tokyo update 2, thinking most of the problems of the first
release of tokyo under android was corrected. Need to say i m fully
disappointed :(

I agree with loki loki. I have found that 3D controls do not function
properly on the Android platform. I have to compile with Berlin for
them to work properly and this is ridiculous.

Clearly there is very little testing done on the 3D side as most of the
original samples are now longer available so, if they do test 3D, what
are they testing?

I had hoped that when Embarcadero moved to the subscription payment
method that this would mean that the bean counters were not in charge
of releases but this doesn't seem to be the case.

I agree that we should post samples that show broken functionality to
the Quality Portal but Embarcadero generally do not respond to these
posts or keep them updated. It is like submitting them into a black
hole.

Ken
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02