Grandi cambiamenti nella classe Draw con la rev. #5382

[vuott]

Vi rendo noto che Minisini comunica quanto segue:

 « Hi,

I have removed the old Draw class and replaced it with a new Draw class
implemented in Gambas inside the gb.gui.base component, that emulates
the old Draw class by using the Paint class.

I'm starting to remove as much X11 specific code as possible in the
Gambas source code, and the Draw class was completely based on the old
deprecated X11 drawing API of GTK+, so...

Many new methods were added to the Paint class to help the
implementation of the Draw emulation class.

Of course (!) expect some quirks:

- The emulation is not perfect yet, and it won't be 100% compatible
pixel to pixel.

- Expect some performance loss, even if I try to avoid them as much as
possible.

- Drawing lines with Cairo is a lot slower that drawing lines with X11,
even if antialiasing is disabled.

- There is a bug at the moment if you imbricate calls to Paint.Begin()
on the same device. It should work, but apparently it does not...

- Source code clean-up is not finished.

But there is one good news: if you have old printing code from Gambas 2
based on the Draw class, you can now use it directly in Gambas 3 without
having anything to change (theoritically).

All that is an investment to the future, when Wayland will replace X11.

Regards,

--
Benoît Minisini »

[vuott]

Seguono messaggi in ordine a detto argomento:


« I know too little about how these things work...
Does this performance loss apply only to GTK+, or does it have effect also
to Qt4?

Jussi lahtinen »



« Qt4 has one drawing model only, so you should not lose too much. Anyway,
you will see that quickly in the IDE: GridView, TreeView, ListView,
ColumnView, IconView, ListBox, MenuButton... All these controls are
entirely implemented with Gambas code now.

Note that there is a bit of speed loss because coordinates in Paint are
Float and not Integer. So the floating-point versions of drawing methods
are used, not the integer ones.

Maybe Qt4 does more optimizations when using integer coordinates, I
don't know. It depends on the drawing instruction I guess...

--
Benoît Minisini »



« OK, thanks, I will see.
I have used drawingarea to visualise rather complicated dynamic data.
And it was already bottleneck when I "fast forward" the data.
I know there is OpenGL, but right now it looks too much to learn, among
other topics.

Jussi Lahtinen »



« You must be very careful with the drawing instructions you use, because
you can easily doing very slow things, especially if you draw images or
pictures.

--
Benoît Minisini »

[md9327]

In effetti, i problemi che credevo risolti in parte con Paint, alla fine sono usciti fuori ugualmente, con lo sviluppo dell'ultimo PgDesigner3.

La velocità di refresh, e il modo con cui viene eseguito, tra cui anche il disegno di grafici, risulta essere sempre troppo lento.

Stò cercando metodi per risolvere queste lentezze, ma non trovo il bandolo della matassa.

Ho anche trasferito il progetto in altri linguaggio, e ho notato che il problema è solo in Gambas, per cui è da escludere un errore nella logica.
Probabilmente si può fare qualcosa per migliorare, ma credo non sia apprezzabile.

Il lavoro che stanno facendo sulle librerie in tal senso, credo sia altamente opportuno, se si vuole che Gambas venga fuori come un linguaggio veramente usabile per tutto.

[vuott]

Aggiungo questo intervento:

« Drawing sector:

At least latest revision has changed behaviour of circle keyword (in Qt4).

This doesn't draw red sector, instead it seems to draw some part of it
which doesn't start from x,y:

Draw.Foreground = Color.Black
Draw.LineWidth = 1
Draw.FillStyle = Fill.Solid
Draw.FillColor = Color.Red
Draw.Circle(x, y, iSize, fStartAngle, fAngle)


Jussi Lahtinen »


« I confirm the regression. I will look at it...
--
Benoît Minisini »


« OK, it should be fixed in revision #5413.

Regards,
--
Benoît Minisini »


« Still something wrong...

By this code I would expect to see two sectors each of them quarter of
whole circle,
now second one (blue) is half of circle.

Draw.FillColor = Color.Red
Draw.Circle(106, 106, 105, 0, Rad(90))
Draw.FillColor = Color.Blue
Draw.Circle(106, 106, 105, Rad(90), Rad(180))

Jussi Lahtinen »


« Fixed in revision #5415.
Regards,
--
Benoît Minisini »


« Something is still different from the original behaviour.
I use same circle commands to draw pie chart and it still fails...

Test output:

Area num. 0: in rads; 0 to 0.89759700342775
Area num. 1: in rads; 0.89759700342775 to 1.79519400685551
Area num. 2: in rads; 1.79519400685551 to 2.69279101028326
Area num. 3: in rads; 2.69279101028326 to 3.59038801371102
Area num. 4: in rads; 3.59038801371102 to 4.48798501713877
Area num. 5: in rads; 4.48798501713877 to 5.38558202056653
Area num. 6: in rads; 5.38558202056653 to 6.28317902399428
Area num. 7: in rads; 6.28317902399428 to 0

It seems that drawing area 7 cover the whole chart.
So it would be:
Draw.Circle(106, 106, 105, 6.28317902399428, 0)

6.28317902399428 is same as Pi(2) or 360 degrees, which means start is same
as end.

I think whole circle should be drawn with this:
Draw.Circle(106, 106, 105, 0, 6.28317902399428)

And this shouldn't draw anything:
Draw.Circle(106, 106, 105, 6.28317902399428, 0)

Jussi Lahtinen »


« Actually the old Draw class was wrong, because you can draw a pie
clockwise (End > Start) or counter-clockwise (End < Start). So only
Start = End should not draw anything (or just a line between the center
and the point at the specified angle).
--
Benoît Minisini »