[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