BGRABitmap / BGRAControls and OSX is it working?

[Josh]

Hi Circular,

I have installed 1.7 trunk and fixes as well as the popup patch
and tested
i downloaded lazpaint from github, and took installed just the bgrabitmap.
downloaded and installed lateset bgacontrols 3.8 i think.

I have tried both commenting out the section in pixel.inc file

I could not find the define in lclbitmap though, so maybe I have done something wrong...

attached video demonstrating ehat is happening on the setup, the black blob on first vid; was a problem with screen capture. the new vid is a bit laggy; due to frame rate used; to reduce file size.

Hopefully you can see the re-drawing 'dragging' even when in the ide, i created a seperate form and dropped some non bgra controls on; to show how it works with that.
When i watched vid; it does seem slow in use; this is not how it appears though.

I created a project from scratch; showing the problem so you can see exactly what I done to create the issue.

https://drive.google.com/file/d/0B_p0sS481ChxNnY3eU1iNDBKM0U/view

I have run the timing test, and I get the
None 7ms
CT 10Ms
Fine 16ms
CD & Fine 18ms

The CPU Usage for the little app goes to 63.9%

[circular]

@esvignolo: Thanks for reassuring me 

@josh: Ok, those times seem reasonable. The None/CT times are slower than on my Windows but that's not so much and that would not explain the slowness of the buttons.

The CPU time goes up because in fact the little apps draws many times in order to measure the drawing time with sufficient accuracy. It is the same here on my Windows.

About the define, apologies it is in fact in BGRAText unit on line 17.

The slowness I can see on the video seem to come from BCButton controls. For example, if you put other BGRAControls, do you get this slowness?

[Josh]

Hi

I have tried comment out the define; this just makes the text displayed very pixelated.

I have tried most of the BGACOntrols and all seem to cause the issue;

If I use the Thememedclock, and enable on the ice form; just moving the cursor over the clock I get the block snail effect.

Not sure where to go from here; my apps use mainly BCButton; bgrashape and some other custom controls..

If you want me to test anything let me know.

I am having the same problem on 2 MACS, one development one and one test MAC that did not have lazarus on it before today. The second video is from this mac

[circular]

Hi josh,

Well the thing is that there are not many people using BGRABitmap on OSX, so not many people to test and give hints on how to optimise.

Do you know how to debug and find out what is slow? I can explain a bit if you like.

What could help as well is to find how to do a DIB section with OSX.

[Josh]

Hi Circular,

I will definately help where I can; time is a bit of a restraint at the moment. So as long as you do not mind delays in testing and replying I can help.

I have created a vid; which shows a live graph of timing issues; the timing is done by a ttimer and analyzing the time it takes for the timer to fire; the time is calcualted less the interval of the timer to get some idea of how much resources are being used; the result is quite startling.
I have also added a visual clock component, which is using bgrabitmap; and you can see the impact this has when the clock is turned on.

Hopefully you can see in the video the image of the clock is coming through a button that is on a panel that is infront of the clock.

Not sure if the vid helps; but hoopefully it helps show the impact and problem.

I have gone back to mac number 1 which has laz 1.44 and fpc 2.6.4 and 9.1_2 installed.


https://drive.google.com/file/d/0B_p0sS481ChxUUEzdXN5RzAzcnc/view

[circular]

Beautiful graph!

I've taken note of your availability.

Can you test the following project, that basically determines how much time it takes to create bitmaps and draw them?

Here on my Windows I get:
- 12 ms for 100 opaque shapes
- 44 ms for 100 non opaque shapes

(you need to increase a bit the total number of shapes for example up to 500 to get an accurate number)

[Josh]

Hi Circular,

Been thinking; how hard would it be to add some timeing analysis something like

Code: [Select]

{Define BGRATimingAnalysis}

{$ifdef BGRATimingAnalysis}
uses lclintf;
type TBGRATiming=record
TimeInterval=LongInt; // Holds the GetTickCount
Name:String[20]; // Description of Holder
Extra:LongInt; // this to be for calculating differences; ie if>0 then val1=extra mod 100; val2 = extra div 100 ; differ=array[val1].timeinterval-array[val2].timeinterval;
end;
BGRATimings:=Array[0..100] of TBgraTiming;

// create values
with BGRATiming[0] do
begin
  timeinterval:=0;
  name:='Before Drawing';
  Extra:=0;
end;

etc.etc.etc.

with BGRATiming[8] do
begin
  timeinterval:=0;
  name:='After Canvas Paint';
  Extra:=0;
end;

with BGRATiming[9] do
begin
  timeinterval:=0;
  name:='Time to complete Canvas Paint';
  Extra:=(0+(8*100));
end;


Then in relevant parts
{$ifdef BGRATimingAnalysis}
BGRATiming[8]:=GetTickCount;
{$endif}

Then on a form either graphs or memos; displaying values: in a timer;
var v:array[0,100] of longint; // holds the values and calculated values
     

For I:=0 to 100 do
begin
  If Name<>'' then
  begin
      with bgratiming[i] do
      begin
          if extra>0 then
          begin
             // result is derived from 1-2
             v[i]:=(bgratiming[(bgratiming[i].extra) mod 100)].timeinterval)-(bgratiming[(bgratiming[i].extra) div 100)].timeinterval);
          end
          else
          begin
              v[i]:=(bgratiming[(bgratiming[i].extra) mod 100)].timeinterval);
          end
      end;
  end;
end;
// update visual;
Memo1.Lines.Add(bgratiming[9].name+IntToStr(v[9])); // = Time to complete Canvas Paint + difference between values in 8 and 0

Just a very rough dirty draft; no syntax checking done; hope it makes sense.


No idea if this sort of thing is possible; or easily to add as an directive for testing

[circular]

I suppose you're talking about adding within BGRABitmap package. That's a good idea.

EDIT: The difficulty with time analysis ("profiling") is that the precision of the internal clock is roughly 15 milliseconds, so that it is not really possible to measure small amounts of time. One workaround would be probabilistic: by determining the elapsed time as grains of 15 milliseconds, if the same thing is done many times, we can compute the average and there is a significant probability that the average reflects the actual time of the individual task.

[Josh]

Hi

My reading are way off
5,000  (approximated)
7,000 (approximated).

[circular]

5000 milliseconds for 100 opaque shapes?

That would explain the slowness.

[Josh]

Hi,

On my windows PC I changed to 2000 shapes, as was a blur.
Opa 8ms
Non Opa  34ms

Drastic differnece.

[Josh]

Also done some test using cocoa
32bit
opa 3732
non opa 51ms
64bit
opa 2583
non opa 51ms

Big difference between Cocoa and Carbon, unfortunately still no even close; also cocoa is still not complete.

It would appear as a novice; that the bulk of the issue is the underlying widgetset...

[Josh]

Hi Circular reference timing. Timing using internal clocks is indeed non reliable; the code could be changed to
as a quick balance you could caclulate any differences as the average of old value to new value to help tame any rapid spike, but it would be enought to hilight the issue.

Or alternatively hold a running total of values displayed and divide by the counter; this would improve accuracy over time.
add to rec structure displayed_count:longInteger;RunningTotal:Int64; Then in displaying form inc displayed_count; and add to runningTotal the difference as caclulated)

Just an idea;

[circular]

Can you try to replace the function DataDrawOpaqueImplementation in BGRALCLBitmap by the following?

Code: Pascal  [Select][+][-]

1. procedure DataDrawOpaqueImplementation(ACanvas: TCanvas; Rect: TRect;
2.   AData: Pointer; ALineOrder: TRawImageLineOrder; AWidth, AHeight: integer);
3. var
4.   Temp:      TBitmap;
5.   RawImage:  TRawImage;
6.   BitmapHandle, MaskHandle: HBitmap;
7.   TempData:  Pointer;
8.   x, y:      integer;
9.   PTempData: PByte;
10.   PSource:   PByte;
11.   ADataSize: integer;
12.   ALineEndMargin: integer;
13.   CreateResult: boolean;
14. begin
15.   if (AHeight = 0) or (AWidth = 0) then
16.     exit;
17.  
18.   if not TBGRAPixel_RGBAOrder then
19.   begin
20.     RawImage.Init;
21.     RawImage.Description.Init_BPP32_B8G8R8_BIO_TTB(AWidth,AHeight);
22.     RawImage.Description.LineOrder := ALineOrder;
23.     RawImage.Description.LineEnd := rileDWordBoundary;
24.     RawImage.Data := PByte(AData);
25.     RawImage.DataSize:= AWidth*AHeight*sizeof(TBGRAPixel);
26.     TempData := nil;
27.   end else
28.   begin
29.     RawImage.Init;
30.     RawImage.Description.Init_BPP24_R8G8B8_BIO_TTB(AWidth, AHeight);
31.     RawImage.Description.LineOrder := ALineOrder;
32.     RawImage.Description.LineEnd := rileDWordBoundary;
33.  
34.     ALineEndMargin := (4 - ((AWidth * 3) and 3)) and 3;
35.     ADataSize      := (AWidth * 3 + ALineEndMargin) * AHeight;
36.  
37.     if integer(RawImage.Description.BytesPerLine) <> AWidth * 3 + ALineEndMargin then
38.       raise FPImageException.Create('Line size is inconsistant');
39.  
40.     PSource   := AData;
41.     GetMem({%H-}TempData, ADataSize);
42.     PTempData := TempData;
43.  
44.     for y := 0 to AHeight - 1 do
45.     begin
46.       for x := 0 to AWidth - 1 do
47.       begin
48.         PWord(PTempData)^ := PWord(PSource)^;
49.         (PTempData+2)^ := (PSource+2)^;
50.         Inc(PTempData,3);
51.         Inc(PSource, 4);
52.       end;
53.       Inc(PTempData, ALineEndMargin);
54.     end;
55.  
56.     RawImage.Data     := PByte(TempData);
57.     RawImage.DataSize := ADataSize;
58.   end;
59.  
60.   CreateResult := RawImage_CreateBitmaps(RawImage, BitmapHandle, MaskHandle, False);
61.   FreeMem(TempData);
62.  
63.   if not CreateResult then
64.     raise FPImageException.Create('Failed to create bitmap handle');
65.  
66.   Temp := TBitmap.Create;
67.   Temp.Handle := BitmapHandle;
68.   Temp.MaskHandle := MaskHandle;
69.   ACanvas.StretchDraw(Rect, Temp);
70.   Temp.Free;
71. end;      

EDIT: Just added TempData := nil; to avoid crash

[Josh]

Hi
I have gone back to carbon
Opa and Non Opa are now very similar
5200  approx
5600  approx

Do you want me to try with cocoa as well, or just stay on carbon