[Customdrawn] Some patches

Giuliano Colla giuliano.colla at fastwebnet.it
Mon Apr 2 12:27:05 CEST 2012


Il 02/04/2012 09:52, Felipe Monteiro de Carvalho ha scritto:
> On Fri, Mar 30, 2012 at 9:50 PM, Giuliano Colla
> <giuliano.colla at fastwebnet.it>  wrote:
>> Here's a new diff, against last revision.
>> I have added some comments, and moved TCDX11Timer from customdrawnint to
>> customdrawn_x11proc.
>> I've added there the include of customdrawndefines, and uses CustomDrawnInt
>> but under ifdef.
> Hello,
>
> Ok, now this is a pretty excellent patch with many comments =)
>
> I applied it, but I had to disabled the new timer by default because
> it crashes one of our test cases:
>
> lazarus/examples/android/nonandroidtest.lpi
>
> It probably crashes the timer of TCDEdit
>
I have used nonandroidtest as one of my benchmark programs, and here it 
worked just fine.
I'll look again once I've updated from svn (now I must go to the 
dentist! -( )
> Sorry for the long delay in applying, but in weekends I am less available.
>
This will be considered in your next salary! =)
> I think that we should consider from now on giving you direct commit
> rights to the customdrawn directory. 1.0 was already branched so there
> will be a long time till trunk becomes a release again and clearly you
> know more about X11 then I do. And I am also focused in the Android
> and Cocoa backends now.
>
I also believe it would make things run more smoothly. I would not touch 
anything non X11 specific without your previous approval, of course.
> My main challange now is to speed up the painting. I already wrote
> many optimizations, but it is still too slow in the Virtual Magnifying
> Glass, which is a full screen application which makes custom drawings.
> In this case there is no easy way to cache operations because it
> really repaints the entire screen each time.
>
Coming back from dentist! =)

This is your domain. My ideas stop at "only update what's necessary", 
unless you're willing to implement some more deep changes.

A solution I've frequently used in other fields, is to use multiple 
buffers, and a separate thread.

A separate thread for painting means, on modern MPU's, that painting 
occurs in parallel with other activities. Multiple buffers means that 
the client thread just fills up the next available buffer, and then 
continues its processing. If the client thread fills buffers at a faster 
rate than the painting thread can handle, the painting thread just skips 
some updates. The user don't notice it, because what gets painted is 
always the most recent image.
It works like that: the painting engine running in its thread, gets a 
buffer to paint. When it's done, it frees the buffer, and looks if there 
are more buffers to paint. If there's more than one, it frees all except 
the last one, and paints the last one. That way you always paint the 
most recent buffer.

It's not a child's play to implement, because you must find the right 
splitting of operations, in order to give each thread an appropriate 
amount of work to do. Then you must activate multithreading (which in 
Lazarus isn't enabled by default, in Unix environment), define what must 
be thread-safe, and what not, etc. etc.

But if slowness is not an X11-only issue, then this approach should be 
considered. After all that's the reason why other widgesets are faster. 
It is not that they're smarter in painting than you. They just 
distribute activity between the main thread and their own threads.

> It also could be faster in scrolling the form in Android.
>
See above.

Giuliano





More information about the Customdrawn mailing list