Is there a cairo like surface for the screen without the window hassle

[Antoon Pardon]

Op 03-02-15 om 13:17 schreef Nobody:
> On Mon, 02 Feb 2015 14:20:56 +0100, Antoon Pardon wrote:
>
>> I need to have a program construct a number of designs. Of course I can
>> directly use a pfd surface and later use a pdf viewer to check. But that
>> becomes rather cumbersome fast. But if I use a cairo-surface for on the
>> screen I suddenly have to cope with expose events and all such things I
>> am not really interested in.
>
> If you're writing a GUI application, something has to deal with those
> events regardless of which rendering API you use.

Sure but from my point of view I am not writing a GUI. I just have a function
that takes a cairo context and draws an image on it. That works all very fine
if it is a postscript of pdf or an image but gives trouble when the context
is associated with a window on the screen.

>> So does someone know of a package that provides a cairo like surface but
>> that would take care of the events in a rather straight forward matter,
>> so that my program could make it's design in a window on the screen just
>> as if it is designing it in a pdf file.
>
> What exactly is the issue here? That you want to be able to construct a
> graphical representation then discard the data used to construct it,
> rather than having to keep it around in order to handle subsequent expose
> events?

I want those expose events handled for me, so I don't have to care for them,
so that I can just use a context that will render the drawing in a window
on the screen without me having to wonder about any event.

> If that's the case, the simplest solution is probably to render to an
> image surface then handle expose events by drawing the image onto the
> screen (or handing the image to some kind of "widget" which does this for
> you).
>
> Another solution is to render to a recording surface. This can then be
> used as a source surface, so handling expose events boils down to a single
> cairo_paint() operation with the recording surface as the source surface
> and the window as the destination surface. Maybe there's even a widget
> somewhere which does this, but I don't know of one.

Yes I had written something like this for pygtk. The module provided an
initiator which you called with a function. This would then start the gtk.main
loop and start the function in a thread. The module provided also a class
similar to a cairo context, which would create a windon and draw into it, it
was implemented more or less as you describe above. The main advantage was that
the function that made the design didn't need to care about being used in a GUI.

Problem is I don't succeed in getting it to work with the new introspective
gtk framework. But since this seems something usefull I thought I ask about
maybe someone else already having written something similar before I sink
more of my own time into it.