Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: Tbitmap are not multithread under tokyo



Permlink Replies: 32 - Last Post: Jan 2, 2018 12:42 AM Last Post By: Dave Nottage
loki loki

Posts: 787
Registered: 7/1/02
Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 8:25 AM
From this post:
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 ?
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 8:35 AM   in response to: loki loki in response to: loki loki
Am 30.12.2017 um 17:25 schrieb loki loki:
From this post:
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 ?

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
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 10:54 AM   in response to: Markus Humm in response to: Markus Humm

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)
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 5:18 PM   in response to: loki loki in response to: loki loki
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
Antonio Estevez

Posts: 665
Registered: 4/12/00
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:25 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
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
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:58 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...

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 ?
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 10:53 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
From this post:
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 ?

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/

loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 11:01 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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 :(

Even reference counting mechanism itself is not thread safe:

https://dalijap.blogspot.com/2017/12/is-it-thread-safe-assume-not.html

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
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 11:40 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
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.


Even reference counting mechanism itself is not thread safe:

https://dalijap.blogspot.com/2017/12/is-it-thread-safe-assume-not.html

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/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 11:58 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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 ;)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:26 PM   in response to: loki loki in response to: loki loki
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
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/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:39 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:41 PM   in response to: loki loki in response to: loki loki
loki loki wrote:
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/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 1:18 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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 )

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:48 PM   in response to: loki loki in response to: loki loki
loki loki wrote:
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/
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 5:33 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:43 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
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

--
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: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 1:28 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
On 12/30/2017 11:43 PM, Dalija Prasnikar wrote:

IDE crash on opening .dproj file through Windows Explorer
https://quality.embarcadero.com/browse/RSP-19676

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 :(

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 3:25 PM   in response to: loki loki in response to: loki loki
Am 30.12.2017 um 22:28 schrieb loki loki:
On 12/30/2017 11:43 PM, Dalija Prasnikar wrote:

IDE crash on opening .dproj file through Windows Explorer
https://quality.embarcadero.com/browse/RSP-19676

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
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 5:54 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

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

Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 5:19 PM   in response to: loki loki in response to: loki loki
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

loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 11:07 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

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 ...
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 11:58 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

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/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 30, 2017 12:10 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

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 :)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 2:47 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
From this post:
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.

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/
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 3:12 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

           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 ....
loki loki

Posts: 787
Registered: 7/1/02
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 4:48 AM   in response to: loki loki in response to: loki loki
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 ...
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 1:51 PM   in response to: loki loki in response to: loki loki
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
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 2, 2018 12:05 AM   in response to: Dave Nottage in response to: Dave Nottage
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
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 2, 2018 12:42 AM   in response to: Markus Humm in response to: Markus Humm
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
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 6:12 PM   in response to: loki loki in response to: loki loki
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
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2017 5:54 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

loki loki wrote:
From this post:
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.
wesley bobato

Posts: 19
Registered: 3/17/10
Re: Tbitmap are not multithread under tokyo
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 1, 2018 2:40 PM   in response to: loki loki in response to: loki loki
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)

Server Response from: ETNAJIVE02