Discussion:
Big change in revision #5382
(too old to reply)
Benoît Minisini
2012-11-27 18:48:20 UTC
Permalink
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
Jussi Lahtinen
2012-11-27 20:26:33 UTC
Permalink
Post by Benoît Minisini
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.
- 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.
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
Benoît Minisini
2012-11-27 20:36:31 UTC
Permalink
Post by Jussi Lahtinen
Post by Benoît Minisini
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.
- 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.
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?
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
Jussi Lahtinen
2012-11-27 20:49:43 UTC
Permalink
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



On Tue, Nov 27, 2012 at 10:36 PM, Benoît Minisini <
Post by Benoît Minisini
Post by Jussi Lahtinen
Post by Benoît Minisini
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.
- 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.
I know too little about how these things work...
Does this performance loss apply only to GTK+, or does it have effect
also
Post by Jussi Lahtinen
to Qt4?
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
------------------------------------------------------------------------------
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
Benoît Minisini
2012-11-27 20:51:33 UTC
Permalink
Post by Jussi Lahtinen
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
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
Rolf-Werner Eilert
2012-11-28 07:43:58 UTC
Permalink
Hi Benoit,
Post by Benoît Minisini
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.
Sounds like an interesting approach. Does it include Printer functionality?
Post by Benoît Minisini
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.
Wow... you invest a lot of time in this, don't you.
Post by Benoît Minisini
- 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).
Ah, here we go - it does include printing, right? Well, now I have a
question about implementation:

In the Gambas2 Draw there was no (or I didn't use) an own event loop,
but the coder had to call Begin and End and all the Drawing procedures
by code.

In the Gambas3 Paint class, there is an event loop which is called once
and running through several events.

How do you cope with this issue when emulating the Draw things? Does it
call a Paint class event loop? And when the interpreter is within that
loop, how can it know which Draw command is to follow next while that
code is somewhere else?

Anyway, I find the new Paint class very useful, and it makes handling
easier to overlook. But it will take some serious revamping of my
printing organisation, as it is based on this eventloop scheme.
Post by Benoît Minisini
All that is an investment to the future, when Wayland will replace X11.
Regards,
Oops :-) My understanding of this was that Wayland is still kinda
experimental playground and is not yet regarded as a serious follower of
X11 (even if "one day"). Maybe I've missed some recent news here?

Regards

Rolf
Rolf-Werner Eilert
2012-11-28 09:12:03 UTC
Permalink
Hi Benoit,

I was curious and tried the latest trunk on my biggest project which has
the old printing code. Just fyi:

Two errors stopped it:

- In TreeView, the .Item delivers NULL instead of the object clicked on,
but only two nodes down. The other nodes above run fine.

- So I tried to call printing with one node above (which would mean
"print for whole school class" instead of "individual name") and it
stopped at "Printer.File =" saying it does not know .File which is
indeed not even mentioned in the help.

Regards

Rolf
Benoît Minisini
2012-11-28 15:00:33 UTC
Permalink
Post by Rolf-Werner Eilert
Hi Benoit,
I was curious and tried the latest trunk on my biggest project which has
- In TreeView, the .Item delivers NULL instead of the object clicked on,
but only two nodes down. The other nodes above run fine.
This is a problem in TreeView so: what do you mean by "but only two
nodes down"??
Post by Rolf-Werner Eilert
- So I tried to call printing with one node above (which would mean
"print for whole school class" instead of "individual name") and it
stopped at "Printer.File =" saying it does not know .File which is
indeed not even mentioned in the help.
I was talking about the Draw class compatibility, not the Printer class.
The new Printer class is different and will stay different.

Regards,
--
Benoît Minisini
Rolf-Werner Eilert
2012-11-28 15:52:24 UTC
Permalink
Post by Benoît Minisini
Post by Rolf-Werner Eilert
Hi Benoit,
I was curious and tried the latest trunk on my biggest project which has
- In TreeView, the .Item delivers NULL instead of the object clicked on,
but only two nodes down. The other nodes above run fine.
This is a problem in TreeView so: what do you mean by "but only two
nodes down"??
I mean this:

Data
|
--Year 2012
|
--Group x
|
--Name XYZ

The issue is with the indivdual names only, but it appeared only now.
Earlier versions were ok (I remember that because I tried this program
with them, too).
Post by Benoît Minisini
I was talking about the Draw class compatibility, not the Printer class.
The new Printer class is different and will stay different.
That's kinda shame because it means I have to organize two different
ways of drawing with two separate drawing procedures for each of them.
But as I haven't started yet I might be over-estimating the effort.
We'll see :-)

I asked because in the help, when you type Paint and press F2, it says:

This class is used for doing anti-aliased painting on the following objects:
Picture.
Image.
DrawingArea.
Printer.
SvgImage.

So I thought I had one and the same complex of methods now to be able to
organize drawing in a DrawingArea and in a Printer. Or am I thinking in
the wrong direction here?

Regards

Rolf
Benoît Minisini
2012-11-28 16:06:04 UTC
Permalink
Post by Rolf-Werner Eilert
Post by Benoît Minisini
I was talking about the Draw class compatibility, not the Printer class.
The new Printer class is different and will stay different.
That's kinda shame because it means I have to organize two different
ways of drawing with two separate drawing procedures for each of them.
But as I haven't started yet I might be over-estimating the effort.
We'll see :-)
Picture.
Image.
DrawingArea.
Printer.
SvgImage.
So I thought I had one and the same complex of methods now to be able to
organize drawing in a DrawingArea and in a Printer. Or am I thinking in
the wrong direction here?
Regards
Rolf
Did you really read my initial mail? Now the Draw class is emulated
through the Paint class. Consequently, it works on printers, so your old
Gambas 2 code that draws on a printer with the Draw class can be used
now with Gambas 3. But not the code that uses the Printer class! But it
should not be a big deal as logically, you are drawing a print page by
page...
--
Benoît Minisini
Rolf-Werner Eilert
2012-11-28 16:25:49 UTC
Permalink
Post by Benoît Minisini
Post by Rolf-Werner Eilert
Post by Benoît Minisini
I was talking about the Draw class compatibility, not the Printer class.
The new Printer class is different and will stay different.
That's kinda shame because it means I have to organize two different
ways of drawing with two separate drawing procedures for each of them.
But as I haven't started yet I might be over-estimating the effort.
We'll see :-)
Picture.
Image.
DrawingArea.
Printer.
SvgImage.
So I thought I had one and the same complex of methods now to be able to
organize drawing in a DrawingArea and in a Printer. Or am I thinking in
the wrong direction here?
Regards
Rolf
Did you really read my initial mail? Now the Draw class is emulated
through the Paint class. Consequently, it works on printers, so your old
Gambas 2 code that draws on a printer with the Draw class can be used
now with Gambas 3. But not the code that uses the Printer class! But it
should not be a big deal as logically, you are drawing a print page by
page...
Yes I did read it, but I think I didn't fully understand.

I guess, this is a hint that helps me sorting out how to reactivate the
old code. Thanks for your time.

But I don't want to conservate the old code by all means, I am willing
to adapt the stuff to the new environment. The only thing I hope to
solve is the question of code organisation. And this is something you
cannot do for me anyway :-)

So on the one hand, it's nice to have a quick way to adapt the old code
to the emulation IF you really are in need of a Gambas 3 feature; but
the old version still runs fine as long as I maintain it within the
Gambas 2 environment. So on the long run it appears wiser to reorganise
the stuff altogether and make it native Gambas 3.

Regards

Rolf

Loading...