|
Replies:
32
-
Last Post:
Jan 2, 2018 12:42 AM
Last Post By: Dave Nottage
|
|
|
Posts:
787
Registered:
7/1/02
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 30.12.2017 um 17:25 schrieb loki loki:
Hello,
what do you mean with random? Directly after creation or some time at
runtime later on after you loaded somehing in or drew anything on it?
Greetings
Markus
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
Hello,
what do you mean with random? Directly after creation or some time at
runtime later on after you loaded somehing in or drew anything on it?
I just made a demo here :
https://quality.embarcadero.com/browse/RSP-19673
When the bitmap is created in a background thread, then sometime it's
contain random data like on the picture i uploaded
sad sad sad, emb is unable to do anything serious 
I buy tokyo for 2 main raison :
1/ for the merging of the UI thread under android => it's was made
without any quality checking (maybe by student) => every app was 2x more
slow than it's was before
2/ for the multi-thread bitmap => seam the same, it's was made without
any quality checking (maybe by student also)
i m very very disapointed because it's took me 5 min to see the problem,
so i can't understand how emb test their products before to release it
(maybe they don't test it)
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
loki loki wrote:
Hello,
what do you mean with random? Directly after creation or some time
at runtime later on after you loaded somehing in or drew anything
on it?
I just made a demo here :
https://quality.embarcadero.com/browse/RSP-19673
When the bitmap is created in a background thread, then sometime it's
contain random data like on the picture i uploaded
sad sad sad, emb is unable to do anything serious 
I buy tokyo for 2 main raison :
1/ for the merging of the UI thread under android => it's was made
without any quality checking (maybe by student) => every app was 2x
more slow than it's was before
2/ for the multi-thread bitmap => seam the same, it's was made
without any quality checking (maybe by student also)
i m very very disapointed because it's took me 5 min to see the
problem, so i can't understand how emb test their products before to
release it (maybe they don't test it)
Both projects run fine in Win10 (and Tokyo 10.2.2, build xxx.2004), the
first one in both modes. The second project does however give an AV
when stopping the exe (but only then).
--
Rudy Velthuis http://www.rvelthuis.de
"New programmers are drawn to multithreading like moths to flame,
with similar results." -- Tweet by Danny Thorpe
|
|
|
|
Posts:
665
Registered:
4/12/00
|
|
El 01/01/2018 a las 2:18, Rudy Velthuis (TeamB, MVP) escribió:
first one in both modes. The second project does however give an AV
when stopping the exe (but only then).
That's because the threads keep running after the form is destroyed
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
Both projects run fine in Win10 (and Tokyo 10.2.2, build xxx.2004), the
first one in both modes. The second project does however give an AV
when stopping the exe (but only then).
me i have the picture i uploaded and an exception when you let the app
running more than 2 or 3 min. did you try the demo bug2.zip ?
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Probably. Without the code it is hard to say what.
Help says:
"Note: You will still require normal thread synchronization
if you share objects between threads, to ensure an object is
not deleted while another thread is using it. Also, be cautious
adding your own synchronization around bitmap access.
It can cause deadlocks."
While certain parts and functionality of TBitmap now supports
multithreading that does not mean you can do absolutely
anything with them across multiple threads.
Even reference counting mechanism itself is not thread safe:
https://dalijap.blogspot.com/2017/12/is-it-thread-safe-assume-not.html
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
Probably. Without the code it is hard to say what.
i m afraid not
code is here :
https://quality.embarcadero.com/browse/RSP-19673
the more evident answer is that is a bug
And it's also evident that emb team lack of a serious (even any) quality
checking of what they do
Remember me, who always say that arc was the worse thing introduced in
Delphi  but in the demo i was in win32 so normally arc no matter here
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Probably. Without the code it is hard to say what.
i m afraid not
code is here :
https://quality.embarcadero.com/browse/RSP-19673
the more evident answer is that is a bug
And it's also evident that emb team lack of a serious (even any) quality
checking of what they do
On the first look your code seems fine more or less. You don't check for nil
before calling Free, but that would not change the outcome. So probably it is a bug.
I cannot reproduce it on my own though.
Remember me, who always say that arc was the worse thing introduced in
Delphi  but in the demo i was in win32 so normally arc no matter here
I posted that not as example ARC is bad or has anything to do with bitmap
issue, but as example how it is easy to misunderstand what is thread-safe
code.
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
On the first look your code seems fine more or less. You don't check for nil
before calling Free, but that would not change the outcome. So probably it is a bug.
I cannot reproduce it on my own though.
need to let the code working several minutes and watch carefully. i
think we need to have a "collision" of the thread to see the bug. was
hard to me to take the screenshoot 
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
On the first look your code seems fine more or less. You don't check for nil
before calling Free, but that would not change the outcome. So probably it is a bug.
I cannot reproduce it on my own though.
need to let the code working several minutes and watch carefully. i
think we need to have a "collision" of the thread to see the bug. was
hard to me to take the screenshoot 
I watched, and watched but nothing. I know multithreading bugs may be
hard to spot.
On the other hand, I managed to crash Delphi trying to debug it and now
it crashes everytime when I try to open that project. More bugs...
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
I watched, and watched but nothing. I know multithreading bugs may be
hard to spot.
On the other hand, I managed to crash Delphi trying to debug it and now
it crashes everytime when I try to open that project. More bugs...
 i have another app where it's much more easy to see to bug, it's
immediate but the code is quite big on this app (it's involve resizing
an image inside a bitmap from background thread).
but i made a screenshoot so you see i m not crazy
i will try to make another demo with more background thread
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
I watched, and watched but nothing. I know multithreading bugs may be
hard to spot.
On the other hand, I managed to crash Delphi trying to debug it and now
it crashes everytime when I try to open that project. More bugs...
 i have another app where it's much more easy to see to bug, it's
immediate but the code is quite big on this app (it's involve resizing
an image inside a bitmap from background thread).
but i made a screenshoot so you see i m not crazy
I don't think you are crazy. I have seen your snapshot in that bug report.
i will try to make another demo with more background thread
Having code that makes it easier to reproduce the issue would be helpful.
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
Having code that makes it easier to reproduce the issue would be helpful.
https://quality.embarcadero.com/browse/RSP-19673
can you try the demo "bug2" that i just uploaded ?
and also here you will even have after some time an exception ... ( me
after around 15s )
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
I watched, and watched but nothing. I know multithreading bugs may be
hard to spot.
On the other hand, I managed to crash Delphi trying to debug it and now
it crashes everytime when I try to open that project. More bugs...
 i have another app where it's much more easy to see to bug, it's
immediate but the code is quite big on this app (it's involve resizing
an image inside a bitmap from background thread).
but i made a screenshoot so you see i m not crazy
i will try to make another demo with more background thread
I got it. Just changed each thread sleep times to different values: 50, 100, 120, 150
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Dalija Prasnikar wrote:
I got it. Just changed each thread sleep times to different values:
50, 100, 120, 150
Didn't do anything for me. All worked fine. Sure, some of the bitmaps
flickered from time to time, but that was not unexpected.
--
Rudy Velthuis http://www.rvelthuis.de
"Learning is not compulsory. Neither is survival."
-- W. Edwards Deming
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
On 12/30/2017 11:43 PM, Dalija Prasnikar wrote:
bug on bug
what make me unhappy is that these kind of bug are very easy to find (me
i just launch an app that use bitmap in multithread to immediately see
it). The demo app i made (bug2 for example) is very simplistic multi
thread bitmap app.
so the question: HOW it's possible that the emb team didn't catch it?
how they test the code they made ? did they really test it ? does the
people they invite in beta testing (Note: they don't invite me anymore,
maybe they prefer to not know anymore that their product is defecting,
playing like Struthio) really test the product ??
as i say, i take tokyo only for 2 raisons:
1/ the merging of the android ui thread => you know my deception 
2/ the multithread bitmap => and another deception
and i think most of problem is because they poorly test their product
before to release it 
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 30.12.2017 um 22:28 schrieb loki loki:
On 12/30/2017 11:43 PM, Dalija Prasnikar wrote:
bug on bug
what make me unhappy is that these kind of bug are very easy to find (me
i just launch an app that use bitmap in multithread to immediately see
it). The demo app i made (bug2 for example) is very simplistic multi
thread bitmap app.
so the question: HOW it's possible that the emb team didn't catch it?
how they test the code they made ? did they really test it ? does the
people they invite in beta testing (Note: they don't invite me anymore,
maybe they prefer to not know anymore that their product is defecting,
playing like Struthio) really test the product ??
I think yes, but it's sometimes difficult I guess if those bigger
projects some of the testers surely have require 3rd party components
which might need adaption or a new version from their vendors to be
compatible.
Difficult.
Btw. if you own a subscription you are automatically eligible for the
"outer" circle of beta testers! They're only added later on afaik, but
still some opportunity for testing.
Greetings
Markus
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Dalija Prasnikar wrote:
On the other hand, I managed to crash Delphi trying to debug it and
now it crashes everytime when I try to open that project. More
bugs...
Ok, project itself is fine, opening through .dproj file is the part
that does not work.
IDE crash on opening .dproj file through Windows Explorer
https://quality.embarcadero.com/browse/RSP-19676
Hmmm... I opened it by clicking the .dproj file in explorer too, but
all worked fine.
--
Rudy Velthuis http://www.rvelthuis.de
"Python's a drop-in replacement for BASIC in the sense that
Optimus Prime is a drop-in replacement for a truck."
-- Cory Dodt
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
loki loki wrote:
On the first look your code seems fine more or less. You don't
check for nil before calling Free, but that would not change the
outcome. So probably it is a bug. I cannot reproduce it on my own
though.
need to let the code working several minutes and watch carefully.
I did. No problem.
--
Rudy Velthuis http://www.rvelthuis.de
"If you're sick and tired of the politics of cynicism and polls
and principles, come and join this campaign." -- George W. Bush
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
sad that we need a google account to answer your blog  and again,
everyone please stop with google, you don't see that they made us slave
of them with all this kind of thing. else it's was interesting ...
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
sad that we need a google account to answer your blog  and again,
everyone please stop with google, you don't see that they made us slave
of them with all this kind of thing. else it's was interesting ...
Sorry...
But Google makes some things easy. I guess that is why everyone is using it.
It is not perfect, but it works.
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
But Google makes some things easy. I guess that is why everyone is using it.
It is not perfect, but it works.
no it's not because of this that everyone is using it 
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
OK, there is something I didn't see yesterday. Maybe it is not a bug after all.
aTmpBitmap := Tbitmap.Create(100,100);
if aTmpBitmap.Canvas.BeginScene then
try
aTmpBitmap.Clear($ff000000);
aTmpBitmap.Canvas.FillText(TRectF.Create(0,0,100,100),
You were calling aTmpBitmap.Clear($ff000000); outside BeginScene. When I
moved it inside it seems like it works fine.
I cannot look at it more at the moment.
--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
aTmpBitmap := Tbitmap.Create(100,100);
if aTmpBitmap.Canvas.BeginScene then
try
aTmpBitmap.Clear($ff000000);
aTmpBitmap.Canvas.FillText(TRectF.Create(0,0,100,100),
You were calling aTmpBitmap.Clear($ff000000); outside BeginScene. When I
moved it inside it seems like it works fine.
I cannot look at it more at the moment.
So if it's this, it's mean all the code source of delphi if wrong also :
ex in unit FMX.ImgList :
function TCustomImageList.DoBitmap(Size: TSize; const Index: Integer):
TBitmap;
var
begin
...
Result := TBitmap.Create(Size.cx, Size.cy);
Result.BitmapScale := 1;
Result.Clear(TColorRec.Null);
if Result.Canvas.BeginScene then
try
...
finally
Result.Canvas.EndScene;
end;
...
end;
but it's not this, i also try yesterday to move the clear inside the
BeginScene, it's just make the bug more rare to appear, but bug is still
here ....
|
|
|
|
Posts:
787
Registered:
7/1/02
|
|
but it's not this, i also try yesterday to move the clear inside the
BeginScene, it's just make the bug more rare to appear, but bug is still
here ....
try to run bug2.zip from
https://quality.embarcadero.com/browse/RSP-19673 (move the clear inside
the beginscene if you prefer), leave it running for some time (1 to 5
min) and you will receive an access violation. You will also see some
bad bitmap drawed on the canvas (but less than when the clear was before
the beginscene).
if not, try to remove the sleep and increase the number of thread ...
|
|
|
|
Posts:
1,850
Registered:
1/7/00
|
|
loki loki wrote:
try to run bug2.zip from
https://quality.embarcadero.com/browse/RSP-19673 (move the clear inside
the beginscene if you prefer), leave it running for some time (1 to 5
min) and you will receive an access violation. You will also see some
bad bitmap drawed on the canvas (but less than when the clear was before
the beginscene).
if not, try to remove the sleep and increase the number of thread ...
I don't experience the problems described, either.
--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 01.01.2018 um 22:51 schrieb Dave Nottage (TeamB):
loki loki wrote:
try to run bug2.zip from
https://quality.embarcadero.com/browse/RSP-19673 (move the clear inside
the beginscene if you prefer), leave it running for some time (1 to 5
min) and you will receive an access violation. You will also see some
bad bitmap drawed on the canvas (but less than when the clear was before
the beginscene).
if not, try to remove the sleep and increase the number of thread ...
I don't experience the problems described, either.
If it is dependent on the graphics card as some suggest, it would be
good to have that information from every tester as well.
But: is the creating of a bitmap really dependant on the graphics card?
Greetings
Markus
|
|
|
|
Posts:
1,850
Registered:
1/7/00
|
|
Markus Humm wrote:
If it is dependent on the graphics card as some suggest, it would be
good to have that information from every tester as well.
But: is the creating of a bitmap really dependant on the graphics card?
So far it seems to be the only difference in the issue that makes any kind of sense. I even used the executable that
loki compiled when I tested, just as a sanity check.
--
Dave Nottage [MVP, TeamB]
Find hints, tips and tricks at Delphi Worlds blog: http://www.delphiworlds.com
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
loki loki wrote:
aTmpBitmap := Tbitmap.Create(100,100);
if aTmpBitmap.Canvas.BeginScene then
try
aTmpBitmap.Clear($ff000000);
aTmpBitmap.Canvas.FillText(TRectF.Create(0,0,100,100),
You were calling aTmpBitmap.Clear($ff000000); outside BeginScene.
When I moved it inside it seems like it works fine.
I cannot look at it more at the moment.
So if it's this, it's mean all the code source of delphi if wrong
also :
ex in unit FMX.ImgList :
function TCustomImageList.DoBitmap(Size: TSize; const Index:
Integer): TBitmap;
var
begin
...
Result := TBitmap.Create(Size.cx, Size.cy);
Result.BitmapScale := 1;
Result.Clear(TColorRec.Null);
if Result.Canvas.BeginScene then
try
...
finally
Result.Canvas.EndScene;
end;
...
end;
but it's not this, i also try yesterday to move the clear inside the
BeginScene, it's just make the bug more rare to appear, but bug is
still here ....
Not here anymore. No flicker, no exception, no nothing. I ran it for at
least 15 minutes and it is still running fine.
--
Rudy Velthuis http://www.rvelthuis.de
"You simply cannot hang a millionaire in America."
-- Bourke Cockran
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Dalija Prasnikar wrote:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Multi-Threading_for_TBitmap,_TCanvas,_and_TContext3D
It's say that under tokyo now TBitmap has complete multi-threading
support. Instances can be created, destroyed, and modified in any
thread without synchronization.
But it's false (i try on win32), yes i can create the instance from
any thread, but the content of the bitmap will be often random like
it's was in berlin
did i miss something ?
OK, there is something I didn't see yesterday. Maybe it is not a bug
after all.
aTmpBitmap := Tbitmap.Create(100,100);
if aTmpBitmap.Canvas.BeginScene then
try
aTmpBitmap.Clear($ff000000);
aTmpBitmap.Canvas.FillText(TRectF.Create(0,0,100,100),
You were calling aTmpBitmap.Clear($ff000000); outside BeginScene.
When I moved it inside it seems like it works fine.
Same here. No flicker anymore.
--
Rudy Velthuis http://www.rvelthuis.de
"Everybody wants to go to heaven, but nobody wants to die."
-- Joe Louis.
|
|
|
|
Posts:
19
Registered:
3/17/10
|
|
Hi loki loki.
I'm really showing off the mistakes.
Windows 7 x64
Attached 2 Videos.
https://quality.embarcadero.com/browse/RSP-19673
GlobalGPUCanvas is very important to me and unfortunately I'm afraid
than the embarcadero will do to correct these errors.
I hope the embarcadero does not make slow GPUCanvas
I was scared to burn my computer my video card is integrated 
|
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us