Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: Regarding Tokyo



Permlink Replies: 4 - Last Post: Jan 4, 2018 3:39 PM Last Post By: loki loki Threads: [ Previous | Next ]
loki loki

Posts: 787
Registered: 7/1/02
Regarding Tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2018 1:38 AM
I want to make a little point of the delphi tokyo focusing mostly on the
new feature they introduce, giving everyone a view of it :

*) About the multi-thread bitmap.

1. Multi-thread bitmap is not working. i open a bug report
https://quality.embarcadero.com/browse/RSP-19673
It's seam that it's depend of the computer, because the same .exe that
fail on my computer work well on some other computer. Anyway what is
sure is that multi-thread bitmap is buggy and must be avoid right now

2. their is something completely crazy regarding TTexture. they seam to
make it multithread by adding lock like for example :

procedure TTexture.UpdateTexture(const Bits: Pointer; const Pitch: Integer);
begin
TMonitor.Enter(Self);
try
...
finally
TMonitor.Exit(Self);
end;
end;

OK, great but what the purpose to add threading lock if the TTexture use
internally messaging system that is absolutely not multithread :

constructor TTexture.Create;
begin
....
TMessageManager.DefaultManager.SubscribeToMessage(TContextLostMessage,
ContextLostHandler);
FContextResetId :=
TMessageManager.DefaultManager.SubscribeToMessage(TContextResetMessage,
ContextResetHandler);
end;

destructor TTexture.Destroy;
begin
TMessageManager.DefaultManager.Unsubscribe(TContextLostMessage,
FContextLostId);
TMessageManager.DefaultManager.Unsubscribe(TContextResetMessage,
FContextResetId);
...
end;

that mean we can not create the texture in background thread, nor use it
in background thread! so what the purpose of the lock ???

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

If Ttexture are not multithread, we can hardly say that graphic is
multithread under android/ios (ttexture is the basement)

*) About the merging of the android UI thread

Was originally a disaster, make the app very slow. it's was because the
paint signal was connected to a Timer (every 16 ms) but timer was not
very accurate and you finally end up with an app 2x more slow, with
jerks etc..

So they change (after severals months of investigation) by a "message
queue", now they post runnable in the main message queue, and even if
the runnable is run before the next frame draw, doesn't matter because
the openGL will freeze the main thread for max 16mx to wait the vsync
signal. that much better than the timer implementation BUT face another
problem: if the drawing process is intensive then you can often lost
some input event (mostly mouse move), because before starting the
drawing the system don't really check if their is some input event
waiting in the queue. this result in some jerk and app slowly
responsible when you move you finger on the screen (because the move
event are not processed in time)

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


*) About the linux compiler

We are at the bottom of every logic! Yes it's was a shame that when we
need to build server app (like isapi dll for exemple) we need to have
server running windows :( so they introduce a linux compiler, without
GUI just for creating server app. GREAT !! But in the obscure mind of
the emb managing staff, they decide to make this new compiler ARC,
breaking compatibility with close to all previous code already written,
and also quite incompatible with server multi-thread app (ARC don't go
well with multithread server app) ! it's a pity :(


*) about emb

lack of communication! Even if i gave her advise about implementation,
they don't take care about it and re implement in their own way. i m not
the only one, many bug report was filled with correction of them, but
they don't care

like for exemple this one :
//https://quality.embarcadero.com/browse/RSP-12782 - i gave this example
because in tokyo they redraw this function, so as they was reprogramming
it (and redebuging it in normal world) they can include the fix ... but
no :( off course it's not like this we will advance :(


*) conclusion

you can make you own conclusion i think ;)

loki loki

Posts: 787
Registered: 7/1/02
Re: Regarding Tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 4, 2018 11:05 AM   in response to: loki loki in response to: loki loki
NOTE: something very (very) great in tokyo (under android) and
absolutely not documented is the implementation of this:

https://quality.embarcadero.com/browse/RSP-14773?jql=text%20~%20%22fragile%22

now texture use 2x less memory and you don't need to worry anymore if
the app go in background/foreground
loki loki

Posts: 787
Registered: 7/1/02
Re: Regarding Tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 4, 2018 11:10 AM   in response to: loki loki in response to: loki loki
and also that now openGL work in background thread :) i try and it's
seam to work pretty well :) just sad they forget to make TTexture
multithread also .... i pretty sure they will do it in the next release
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Regarding Tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 4, 2018 2:32 PM   in response to: loki loki in response to: loki loki
Am 04.01.2018 um 20:10 schrieb loki loki:
and also that now openGL work in background thread :) i try and it's
seam to work pretty well :) just sad they forget to make TTexture
multithread also .... i pretty sure they will do it in the next release

Now finally Tokyo is good for something, eh? ;-)
Now if they can fix the other things...

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Regarding Tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 4, 2018 3:39 PM   in response to: Markus Humm in response to: Markus Humm

Now finally Tokyo is good for something, eh? ;-)
Now if they can fix the other things...

I m still testing ... if only the emb dev team can discuss a little of
what they are doing could be much more great! I guess stupid emb rules
that forbid emb staff to discuss about the code they do/did
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02