[Customdrawn] New fast bitmap copying

Giuliano Colla giuliano.colla at fastwebnet.it
Tue Apr 10 17:52:57 CEST 2012

Felipe Monteiro de Carvalho ha scritto:
> Hello,
> I added a new option to disable the form background manually as
> requested in the forum, and so I used it and also changed the
> magnifier code to draw in the form OnPaint event instead of inside a
> sub-control. The result was a massive speed gain:
> [TCDWSCustomForm.DrawRawImageToGC] Paint duration: 61 ms
> [TCDWSCustomForm.EvPaint] Total Paint duration: 185 ms of this
> CustomDrawn: 185 ms Native: 0
> X11 event WM_PAINT - Window 85983234, Delay 1 ms
> The speed was gained mostly by drawing to the canvas directly instead
> of first to the bitmap.
> But using LCL-Gtk2 now the drawing is lightning fast. I didn't measure
> it, but it is extremely fast! Probably 20 to 30 FPS... so we have some
> catch up to do =D
> I think that reusing the X native image should be something to think
> of. In Android I commited a patch which I received to reuse the native
> bitmap and things are getting really fast in Android =) The guy said
> he is getting 60FPS using LCL-CustomDrawn + Graphics32 in Android!!!
> =D My little interface is getting more and more traction and adoption.
> I always said that there is no secret solution here, just optimize,
> optimize and optimize and the drawing starts flying.
> Anyway I guess that now finally I have a good enough speed to be able
> to make a Mac OS X release of the VMG with LCL-CustomDrawn =) But
> first I have to implement native menu and TTrayIcon support in the
> Cocoa backend ... and also check if the native image can be reused in
> Mac OS X too.
I'm afraid that in the next two weeks I'll have little or no time at all 
to devote to Customdrawn, because of last minute tight schedule needs by 
our customers. As they pay not only for my meals, but also for the 
facilities I can take advantage of, also in behalf of Customdrawn, they 
take precedence =)
I just had time for a few cosmetic adjustments (such as getting color 
depth and image format from X, instead of figuring it out), and I 
believe I have located what's missing to make TrayIcon to work under 
X11, but I had no time to fix it. I'd better update from svn before 
sending patches, but there's not such a hurry. They won't change our 
life. ;-)

I agree with you that basic optimization is very important. If painting 
is too slow, nothing else will help. However there's another point which 
I believe deserves some attention. In the current implementation of 
Customdrawn, at least as far as X11 is concerned, I've seen a difference 
with respect to other widgesets.

In other widgesets, all painting occurs when ProcessMessages is 
executed, i.e. at the end of the main loop. LCL calls the WS methods, 
which make any required housekeeping, and then queue a message, for the 
actual painting. This makes a number of optimizations much easier, 
because at the end of main loop one has all elements in hand, and one 
can avoid useless or multiple paints.
In Customdrawn painting occurs earlier, and this is IMHO a source of 
poor performance.
e.g. Changing a widget position means changing both Top and Left 
property. They're changed with two separate instructions. If there's one 
paint for Top change, and one for Left change, you paint twice. If you 
wait the end of Main Loop, both Top and Left are changed, and just one 
paint is required. And at that level one can paint directly on the 
native canvas.
In order to implement this behavior, one should create a message queue 
on Customdrawn, which may require some work, but is much less 
revolutionary than using different threads, and may turn out very 
effective, for all backends.

What's your opinion about that?


Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

More information about the Customdrawn mailing list