[Gambas-user] Again on DrawingArea

[Benoit Minisini]

On Monday 01 August 2005 11:31, PV wrote:
> On 01/08/2005 02:28, Rob wrote:
> > I have no idea what happened, but when using any language and any
> > graphical toolkit that fires a redraw event, I always make a global
> > (or module-level) variable called something like CurrentlyRedrawing,
> > check to see if it's nonzero at the beginning of the draw event code,
> > exit if it is, set it if it's not, and unset it at the end of the
> > draw event.
>
> Rob, thanks for your suggestion.
>
> However in this case it is of no use because it seems that the Draw event
> is triggered sequentially, so that, when it is called, CurrentlyRedrawing
> is set, the drawing routines are performed, CurrentlyRedrawing is cleared
> and then the Draw event is fired again, and since CurrentlyRedrawing has
> been cleared, the Draw event is repeated in an endless loop anyway.
>
> Playing a bit more with the code instead, I finally spotted the glitch, or
> at least a part of it.
> It appears that setting DrawingArea1.Background and/or
> DrawingArea1.Backcolor inside the Draw event is what is causing the code to
> loop and consequently the 100% CPU usage.
>
> Please note however that in versions < 1.9.13 these same lines of code
> weren't doing any harm and the redrawing speed was visibly greater.
> I will investigate more... :-)
>
>
> Ciao,
> Piero
>

Here is more informationabout the DrawingArea internal stuffs :-)

It is related to the way QT manages draw events sent by the X Server.

First, you must know that a draw event is a rectangle in your window that you 
must redraw.

Then there is two ways:

1) All X11 draw events are merged by QT into a Region object, that is not 
rectangular, and then the QT paint event is called, and thus the Gambas Draw 
event. All drawings during the draw event handler will be clipped by this 
region.

It worked like that before my modifications.

2) QT merges nothing, and you get one Gambas draw event for each X11 draw 
event. The drawing is clipped by the rectangle

It works like that now.

Why doing that ?

Logically, during the drawing event handler, you have to draw the less 
possible things to speed up the drawing.

The only way in Gambas to know what to draw is the Clip.[X/Y/W/H] properties 
of the Draw class.

In the first case, as drawing is clipped by the region, Clip.[X/Y/W/H] returns 
the smalles rectangle that includes the region.

But, for example, when you enlarge a little a window, the region contains two 
rectangles: one at the right of the window, the other at the bottom. And so, 
the including rectangle is the entire window!

+--------------------------------+---+
|                                | x |      xxx = The region used by QT
|                                | x |
|                                | x |
|                                | x |
|                                | x |
|                                | x |
|                                | x |
|                    Old size    | x |
|                                | x |
+--------------------------------+ x |
|xxxxxxxxxxxxxxxxxxxxx New size xxxx |
+------------------------------------+
                               
When you can easily draw any sub-rectangle of your drawing area, the second 
way is the better.

When you can't easily do that, i.e. when your drawing is too complex to be 
easily splitted into a rectangle, you prefer drawing everything each time you 
receive a Draw event. And so, you do the job twice or more times comparing to 
the first way. So it is twice or ore slower.

I think you are in that case. Am I wrong ?

The solution will be having a property in the DrawingArea to tell it merging 
or not drawing events. I think I will do that.

Regards,

-- 
Benoit Minisini
mailto:gambas at ...1...