[gtkada] Heap corruption and other problems

[Dmitry A. Kazakov]

On Mon, 12 Aug 2013 06:27:37 -0700, you wrote:

>> On Sun, 11 Aug 2013 23:20:49 -0700, you wrote:
>>
>>> I have been using GtkAda more to see if I can get something of what I
>>> had before running.  It seems that
>>> my dependence on main_loops and a task router is not working, along with
>>> setting an Event_Handler.  So it
>>> seems that I have make my own infinite loop and check for pending
>>> events.
>> I don't understand why are you doing it in this way. It is relatively
>> simple to have a custom drawn widgets (or cell renderers). I did it both
>> based on GDK and lately in Cairo. I also successfully ported GDK based
>> widgets to Cairo, which is not very difficult, just tedious.
>>
>> It seems to me that you rather have a design problem relying on events you
>> don't need to catch.
> I was doing it that way because a few years back someone changed Gdk and 
> it wasn't working and was in a
> tight loop all the time and not getting updates.  Actually it was you 
> who gave me the code to make it
> work.

If so, then it must be no different to what I already successfully ported
to cairo. So let me insist that there is no need to catch these events.

The major problem I faced was resizing. The "configure-event" cannot be
caught and allocated size never goes down for my base widget, which was
Gtk_Fixed_Record. I needed Gtk_Fixed_Record because it had sliders
superimposed on it and standard background. For Gtk_Fixed_Record allocation
sizes grows when you enlarge the widget's container, but remains same
otherwise.

That problem was solved by overriding get preferred width/height "virtual"
operations. They are no events in Gtk3, as they were in Gtk2. I found a way
to override them (it is in the bindings actually) and made preferred
width/height returning 1 pixel and it works now.

> I took a working example with GDK/Cairo and have been building it up.  
> My only issue now is that it get
> this weird redrawing effect.  It is like I am drawing a bitmap over and 
> over and over.

Is your widget a descendant of Gtk_Drawing_Area_Record?

Gtk uses double buffering, so you should never experience visual
distortions like partial drawing and re-drawing.

> Can see it easily
> as my graphics card is not the fastest but still fast enough to draw.

As I said, there is something wrong with the way you handle it. You should
simply catch "draw" and use the cairo context it comes with. You may also
draw on other events, e.g. doing mouse tracking, by getting the context
from the widget's window. Of course you should keep track of that
internally and be prepared to repeat exactly same drawing from "draw".

>>> Cairo seems to be taking care of all the draw events but I
>>> have notice that my handler is
>>> being called way too much and I think using Ada delays (I know it is not
>>> a desired approach) drops drawing
>>> events.
>> In fact, new Cairo works pretty well. I successfully ported this library
> So you upgraded away from what the GTKAda folks have provided for 
> cairo?

No, I used cairo from GtkAda 3.4. Prior to GtkAda 3.4 it was Damien's cairo
bindings, which were higher level than ones from GtkAda. I ported AICWL to
the GtkAda 3.4 Cairo.

>> to GtkAda 3.4. Everything worked smoothly, after fixing some subtle issues
>> with Pango (which is a bit broken, but nothing one could not work around).
>> I cannot release AICWL though, because of the problems with GTK. They do
>> not affect this library because it practically does not use dynamic memory
>> upon rendering.

> I found a few Pango problems.  Especially bindings that were missing 
> that I had to add in.

Yes, I remember some operation, but they weren't actually needed in the
end. What I did is a controlled Ada font type with cairo toy font and pango
font back-ends. Because toy and pango font interfaces have nothing in
common.

> The method
> was there but not in the binding.

One of my problems was that Pango extents is calculated wrong (Get_Extents
is broken). I used Get_Pixel_Extents instead. Another problem was that the
logical rectangle of the extents seems to use capital letters. It is the
ink rectangle one should use (ignoring the documentation stating
otherwise).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de