Re: [wx-dev] Using Cairo from wxWidgets
klaas.holwerda
> so I suggest we should
> aim at simply making use of Cairo on all platforms
> in the form of a new Canvas widget
>
It would be really easy to adept wxArt2D to use cairo too.
Or if it really becomes available on all platforms, i can use the C++
wrapped cairo as i see it there, without much effort.
http://cairographics.org/documentation/cairomm/reference/index.html
The only problem i see is the wxImage does not fit cairo_format_t.
As it does not fit OpenGl or anything else.
Do i understand you right that this canvas would not know what wxDC means?
In that case i see it is a good choice.
>
> I'd be interested what the MSW developers think
> about what it would take to use Cairo with the
> wxMSW paint logic etc.
>
wxBitmap and wxImage to RGBA is where the problems will be i think.
Writing wxCairoDC is oke for most drawing things, but when it comes to
blit and drawbitmap, all needs to be converted constantly. This is the
same problem with using Antigrain.
As i mentioned a long time ago, i think that wxBrush and wxPen should be
reorganized.
They should be complete platform independent, containing no platform
dependent classes, just information which tells how to fill or stroke.
Once set to the wxDC it ( underlyings brush/pen/stroke/fill system ) can
be set in a way that is suitable for a platform/drawing library. And if
a platform can not do a certain trick ( like gradient in a wxDC, we
emulate it or do something simpler instead.)
This would open the way to gradients and what not. ( see cairo_pattern_t
or better Cairo::Pattern in C++ binding )
This change would make a transition from wxDC to an advanged (path
driven) drawing context much easier.
And the best thing of cairo is for course Cairo::RefPtr, i call mine
a2dSmrtPtr ;-)
This makes brushes and pens ordinary pointers again, and that is fast.
And derived brushes for all future brushes and pens are no problem.
http://cairographics.org/documentation/cairomm/reference/classCairo_1_1Pattern.html
http://wxart2d.sourceforge.net/docs/docbook_html/classa2dFill.html
http://wxart2d.sourceforge.net/docs/docbook_html/classa2dStroke.html
So maybe we need a wrapper around cairo that makes a stroke and fill
still possible ( or wxBrush wxPen if made suitable ).
Cairo only has it settable to the drawing context ( line ends etc ), i
did not find classes that can be used to store that info.
This i how i did it ( still strugling with wxBitmap :-( ):
http://wxart2d.sourceforge.net/docs/docbook_html/classa2dDrawer2D.html
regards,
Klaas
Mart Raudsepp
> Mart Raudsepp wrote:
>
> > Robert Roebling wrote:
> > >
> > > you will probably have noted that the newest GTK+
> > > version use and depend on Cairo, a vector based
> > > 2D graphics engine. It has been disegned to be
> > > platform independent and has numerous backends,
> > > including ones for X11, Windows' GDI, PDF and
> > > more for Quartz and native printing for all of
> > > them. I don't think we have resources to design
> > > something similar ourselves and there is also no
> > > sense in doubling the work, so I suggest we should
> > > aim at simply making use of Cairo on all platforms
> >
> > Cairo and canvas widgets are not directly related.
> > Cairo is a drawing library with an API similar to that
> > of PostScript, there is not much canvas functionality
> > in it, but of course cairo can be used to do the
> > drawing bits and some more things.
>
> That is what I meant.
Ok, had my doubts about the meaning of "canvas" in this context. The
definition of canvas is much more sophisticated in my book. Including,
but not limited to automatic tracking of items on the canvas as to
easily move them around, zoom, etc.
> > Meanwhile I've been having implementing a wxCairoDC
> > high up in my task list, and I might reach that point
> > soon to tackle it. Would it be worthwhile?
>
> Actually, I don't think so. The GDK API is well
> enough for the current, integer based drawing API
> that wxWidgets uses in its in wxDC classes. The
> 2D drawing model, that wxWidgets uses right now
> is good and proven, can be made to work on all
> platforms somehow and was probably better than
> the X11-based drawing API used in GTK, but the
> advent of Cairo, GDI+ and Quartz (in reverse
> order) and the main point is that work is being
> done or has been done to add hardware acceleration
> to this "next generation" API, so they will also
> improve in terms of speed.
> We can try to redo what Cairo has been done or
> is currently doing, but this seems like a waste
> of time and it would be a very nice thing if both
> GTK and wxWidgets would offer the same 2D drawing
> model and API - making moving from one to the other
> very easy.
I see a couple benefits in implementing wxDC in terms of cairo.
a) wxDC users will get anti-aliasing, and accelerated drawing (no-one
will port GdkGC stuff to cairo, they are deprecated and will stay with
primitive X level drawing calls)
b) It will be possible to do limited floating point alike drawing by
using a transformation matrix (SetUserScale and co in our API) - e.g
drawing at 0.1 precision by multiplying every coordinate and length by
10, and setting a user scale of 0.1
c) Knowledge gathered about cairo for the implementor of wxCairoDC, and
for others.
I agree that in the longer run a PostScript alike drawing model would be
better.
> > > This is pretty easy under GTK+, where you get a
> > > Cairo context for each widget anyway, and it
> > > should be easy to use under MSW as well, the
> > > Quartz backend ist still under developent.
> >
> > The Windows backend isn't all that speedy yet either, iirc.
> > But that's certainly subject to change.
>
> I'm sure it will improve.
Certainly, that's what I had in mind with subject to change :)
> > > I'd be interested what the MSW developers think
> > > about what it would take to use Cairo with the
> > > wxMSW paint logic etc.
> >
> > Unfortunately I think cairo would have to stay optional
> > for all ports, but that should be achievable.
>
> Yes, of course. It should be a add-on lib like the
> OpenGl library. I just looked at the API in Cairo 1.0.2
> and it just draws into a Win32 DIB, so all we'd have
> to do in the first step is to create a backing store
> DIB under Windows (let Cairo create it) and blit it
> on screen in a paint event. Under GTK, we'd have to
> do nothing, just pass the Cairo context to the user.
> It will probably be trickier to do printing, but
> I read somewhere that this, too, is being fixed and
> that the next version will support native printing
> also under all platforms - either way, being able
> to draw nicely on screen would be a first step.
> I suggest further to wrap the Cairo API in a 1:1
> wx2D API - later we could even write a wxDC class
> that uses wxCairo context internally so that it
> would be possible to draw with existing code into
> such a window. Doing scrolling will probably be
> a bit trickier under Windows.
I suppose if we first had wxCairoDC, and later wx2D, porting wxCairoDC
over to use wx2D instead of cairo directly would be pretty much
straightforward.
We can discuss this new API, of course, and even start implementing it
at some point. But I still have the plans to do a wxCairoDC - it's as
much as a way to learn cairo better myself, as to get better drawing
into wxDC.
Perhaps lets not use the term "canvas" here for the new drawing model,
it's a controversial term and for many it means a generic engine for
structured graphics - a window with a collection of graphical items
inside it and the canvas will take care of all drawing operations on its
items and allows easy implementation of interactive behaviour on the
items.
Regards,
Mart Raudsepp
Robin Dunn
> Hi all,
>
> you will probably have noted that the newest GTK+
> version use and depend on Cairo, a vector based
> 2D graphics engine. It has been disegned to be
> platform independent and has numerous backends,
> including ones for X11, Windows' GDI, PDF and
> more for Quartz and native printing for all of
> them. I don't think we have resources to design
> something similar ourselves and there is also no
> sense in doubling the work, so I suggest we should
> aim at simply making use of Cairo on all platforms
> in the form of a new Canvas widget.
> Cairo context for each widget anyway, and it
> should be easy to use under MSW as well, the
> addition to 2D drawing, it also uses Pango for
> its text layout and Pango has native backends
> for X11, Uniscribe and recently ATSUI, so again
> something supporting all three major platforms.
>
> I'd be interested what the MSW developers think
> about what it would take to use Cairo with the
> wxMSW paint logic etc.
There has been some interest in this from some wxPython users as well.
I havn't looked real hard at Cairo yet, but I think it would be a good
idea, at least as an optional lib. There was also some interest in
doing the same type of thing with the Agg library.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Mart Raudsepp
> Hi all,
>
> you will probably have noted that the newest GTK+
> version use and depend on Cairo, a vector based
> 2D graphics engine. It has been disegned to be
> platform independent and has numerous backends,
> including ones for X11, Windows' GDI, PDF and
> more for Quartz and native printing for all of
> them. I don't think we have resources to design
> something similar ourselves and there is also no
> sense in doubling the work, so I suggest we should
> aim at simply making use of Cairo on all platforms
> in the form of a new Canvas widget.
Cairo and canvas widgets are not directly related. Cairo is a drawing
library with an API similar to that of PostScript, there is not much
canvas functionality in it, but of course cairo can be used to do the
drawing bits and some more things.
However, there are numerous cairo based canvas widgets in the works
(very active discussion going on at gtk-devel-list and cairo ml, as we
speak), and they are striving for the best API, code, and so on.
Collaboration going on, etc. Perhaps we should wait out what happens
there and perhaps chime in as well?
Meanwhile I've been having implementing a wxCairoDC high up in my task
list, and I might reach that point soon to tackle it.
Would it be worthwhile?
I was thinking about making wxClientDC have a pimpl approach and use the
cairo based DC instead of the GdkGC based one when GTK+ runtime is at
least 2.8.
It would be pretty much cairo centric, with perhaps some pango in it for
the font bits. So from there we can work on top of that code and make it
be more generic - have the acquiring of the cairo context depend on
where we run:
* gdk_cairo_create if GTK+ runtime is 2.7/2.8 or newer - that will give
us a pre-existing cairo context for the GtkWidget.
* selectability for a backend and then calling the appropriate cairo
surface and context creation functions, including one for wxGTK when GTK
runtime is not new enough to include gdk_cairo_create.
> This is pretty easy under GTK+, where you get a
> Cairo context for each widget anyway, and it
> should be easy to use under MSW as well, the
> Quartz backend ist still under developent.
The Windows backend isn't all that speedy yet either, iirc.
But that's certainly subject to change.
> In
> addition to 2D drawing, it also uses Pango for
> its text layout and Pango has native backends
> for X11, Uniscribe and recently ATSUI, so again
> something supporting all three major platforms.
>
> I'd be interested what the MSW developers think
> about what it would take to use Cairo with the
> wxMSW paint logic etc.
Unfortunately I think cairo would have to stay optional for all ports,
but that should be achievable.
--
With regards,
Mart Raudsepp
Project manager of wxMUD
E-mail: le...@dustbite.net
http://wxmud.sourceforge.net/
Robert Roebling
> Robert Roebling wrote:
> >
> > you will probably have noted that the newest GTK+
> > version use and depend on Cairo, a vector based
> > 2D graphics engine. It has been disegned to be
> > platform independent and has numerous backends,
> > including ones for X11, Windows' GDI, PDF and
> > more for Quartz and native printing for all of
> > them. I don't think we have resources to design
> > something similar ourselves and there is also no
> > sense in doubling the work, so I suggest we should
> > aim at simply making use of Cairo on all platforms
> > in the form of a new Canvas widget.
>
> Cairo and canvas widgets are not directly related.
> Cairo is a drawing library with an API similar to that
> of PostScript, there is not much canvas functionality
> in it, but of course cairo can be used to do the
> drawing bits and some more things.
That is what I meant.
> Meanwhile I've been having implementing a wxCairoDC
> high up in my task list, and I might reach that point
> soon to tackle it. Would it be worthwhile?
Actually, I don't think so. The GDK API is well
enough for the current, integer based drawing API
that wxWidgets uses in its in wxDC classes. The
2D drawing model, that wxWidgets uses right now
is good and proven, can be made to work on all
platforms somehow and was probably better than
the X11-based drawing API used in GTK, but the
advent of Cairo, GDI+ and Quartz (in reverse
order) and the main point is that work is being
done or has been done to add hardware acceleration
to this "next generation" API, so they will also
improve in terms of speed.
We can try to redo what Cairo has been done or
is currently doing, but this seems like a waste
of time and it would be a very nice thing if both
GTK and wxWidgets would offer the same 2D drawing
model and API - making moving from one to the other
very easy.
> > This is pretty easy under GTK+, where you get a
> > Cairo context for each widget anyway, and it
> > should be easy to use under MSW as well, the
> > Quartz backend ist still under developent.
>
> The Windows backend isn't all that speedy yet either, iirc.
> But that's certainly subject to change.
I'm sure it will improve.
> > I'd be interested what the MSW developers think
> > about what it would take to use Cairo with the
> > wxMSW paint logic etc.
>
> Unfortunately I think cairo would have to stay optional
> for all ports, but that should be achievable.
Yes, of course. It should be a add-on lib like the
OpenGl library. I just looked at the API in Cairo 1.0.2
and it just draws into a Win32 DIB, so all we'd have
to do in the first step is to create a backing store
DIB under Windows (let Cairo create it) and blit it
on screen in a paint event. Under GTK, we'd have to
do nothing, just pass the Cairo context to the user.
It will probably be trickier to do printing, but
I read somewhere that this, too, is being fixed and
that the next version will support native printing
also under all platforms - either way, being able
to draw nicely on screen would be a first step.
I suggest further to wrap the Cairo API in a 1:1
wx2D API - later we could even write a wxDC class
that uses wxCairo context internally so that it
would be possible to draw with existing code into
such a window. Doing scrolling will probably be
a bit trickier under Windows.
Robert
Mart Raudsepp
> I'd love to have a consistent, powerful vector drawing API on all
> platforms, but I'm a little worried about it being Cairo. Sadly, I
> don't have any other suggestions
There's also the Amanith framework (Crossplatform & open source C++
Vector Graphic Framework), of course there's also Anti-Grain Geometry,
and I'm sure there are some others. Something more to consider.
Personally I haven't used any of those yet.
> - I don't think wrapping
> cairo/gdi+/quartz in a common API would really be cost effective, the
> drawing models and capabilities of the toolkits vary widely (GDI+ in
> particular maintains much of the GDI model and isn't nearly as
> powerful as cairo). If we wanted to take this route I'd suggest a
> wxCairoDC/wxGDIPlusDC/wxQuartzDC instead of a new API.
Regards,
Mart Raudsepp
Robert Roebling
> Chris Mellon wrote:
>
> > I'd love to have a consistent, powerful vector drawing API on all
> > platforms, but I'm a little worried about it being Cairo. Sadly, I
> > don't have any other suggestions
>
> There's also the Amanith framework (Crossplatform & open source
> C++ Vector Graphic Framework), of course there's also Anti-Grain
> Geometry, and I'm sure there are some others. Something more to
> consider.
There are other libraries for 2D drawing available, but none
has something like Pango for rendering text in any variant
using native rendereing engines on each platform. I don't
know if any of these has the backing that Cairo has. Let's
also mention that Cairo is the native API under one main
platform against zero for all other libraries.
Robert
Chris Mellon
The speed is a concern, and I'm not sure that the MSW back end is a
priority for the Cairo team. But an even bigger concern for me is the
dependencies - using cairo to do our drawing on all platforms means a
signfigant set of extra libs on Windows. We need cairo itself, of
course, and pango for text layout, which means glib, which means iconv
and gettext. I'm not sure how good the Pango/win32 font support is
either, so it might also mean Freetype and fontconfig. It's not
insurmountable but that is a lot of packages by a lot of different
developers, and not all of them have good windows support or the level
of compiler support that we maintain for wx.
I'd love to have a consistent, powerful vector drawing API on all
platforms, but I'm a little worried about it being Cairo. Sadly, I
don't have any other suggestions - I don't think wrapping
cairo/gdi+/quartz in a common API would really be cost effective, the
drawing models and capabilities of the toolkits vary widely (GDI+ in
particular maintains much of the GDI model and isn't nearly as
powerful as cairo). If we wanted to take this route I'd suggest a
wxCairoDC/wxGDIPlusDC/wxQuartzDC instead of a new API.
> > > I'd be interested what the MSW developers think
> > > about what it would take to use Cairo with the
> > > wxMSW paint logic etc.
> >
> > Unfortunately I think cairo would have to stay optional
> > for all ports, but that should be achievable.
>
I think it's critical that we maintain our existing wxDC
implementions, for use with native drawing constructs like the theme
engine in Windows.
> Yes, of course. It should be a add-on lib like the
> OpenGl library. I just looked at the API in Cairo 1.0.2
> and it just draws into a Win32 DIB, so all we'd have
> to do in the first step is to create a backing store
> DIB under Windows (let Cairo create it) and blit it
> on screen in a paint event. Under GTK, we'd have to
> do nothing, just pass the Cairo context to the user.
> It will probably be trickier to do printing, but
> I read somewhere that this, too, is being fixed and
> that the next version will support native printing
> also under all platforms - either way, being able
> to draw nicely on screen would be a first step.
> I suggest further to wrap the Cairo API in a 1:1
> wx2D API - later we could even write a wxDC class
> that uses wxCairo context internally so that it
> would be possible to draw with existing code into
> such a window. Doing scrolling will probably be
> a bit trickier under Windows.
>
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-un...@lists.wxwidgets.org
> For additional commands, e-mail: wx-de...@lists.wxwidgets.org
>
>
Timothée Lecomte
wxWidgets together !
I have chosen to use Cairo+Pango in the wxWidgets app I am writing (a
graphic 'terminal' for gnuplot - see
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1267434&group_id=2055
for details).
I am successfully using it on both wxGTK and wxMSW, and the implementation
was not that difficult. All of the drawing API of cairo is independant of
the 'surface' where you are drawing to, you just have to care about the
surface creation itself, which may be a Windows HDC, a XDrawable (or a
GdkDrawable), or an offscreen surface (postcript, png, svg, or a raw
buffer).
I have chosen Cairo because it is more powerful than the current wxDC
implementation, in the sense that it supports antialiasing on every path,
and with Pango it makes a perfect couple for precise characters
positionning.
Actually, it seems to me that Cairo/Pango is the best choice for the
long-run in terms of cross-platform drawing API. It is already implemented
in GTK which also runs on Windows, and it is used in Mozilla Firefox for
rendering svg, and Firefox developpers are going to use it for all their
rendering work (see
http://developer.mozilla.org/devnews/index.php/2006/02/22/cairo-is-being-switched-on-for-windows-nightly-builds/
).
As far as speed is concerned, I don't see much difference between GTK and
Windows, and under some conditions it even seems faster on Windows. And,
needless to say, the rendering of the fonts is perfect under each
platform.
By the way, I somebody wants to reuse my code, although it is licensed
under the gnuplot license, I am ready to license it under GPL.
Best regards,
Timothée Lecomte
klaas.holwerda
Timothée Lecomte wrote:
>
> I am successfully using it on both wxGTK and wxMSW, and the implementation
> was not that difficult.
wxMSW using VC? Do you have make file or maybe project files?
Where to get the pango stuff?
Or did you use Cygwin?
I am sure interested to know how to set it up in windows.
> All of the drawing API of cairo is independant of
> the 'surface' where you are drawing to, you just have to care about the
> surface creation itself, which may be a Windows HDC, a XDrawable (or a
> GdkDrawable), or an offscreen surface (postcript, png, svg, or a raw
> buffer).
>
Right, but if you have say a wxImage with alpha to draw or a wxBitmap
what should one do to draw those?
>
> As far as speed is concerned, I don't see much difference between GTK and
> Windows, and under some conditions it even seems faster on Windows. And,
> needless to say, the rendering of the fonts is perfect under each
> platform.
>
Does it already use OpenGL? This Amanith is doing that, only the licence
does not fit. Only LGPL will do.
Having a nice drawing context is great, but i found that currently
alpha usage in wx is a problem to draw quickly.
In any case its the best choice as far as i can see.
regards,
Klaas
Timothée Lecomte
>
> Timothée Lecomte wrote:
>>
>> I am successfully using it on both wxGTK and wxMSW, and the
>> implementation
>> was not that difficult.
> wxMSW using VC? Do you have make file or maybe project files?
> Where to get the pango stuff?
> Or did you use Cygwin?
> I am sure interested to know how to set it up in windows.
I use MinGW, and the zip provided in :
ftp://ftp.gtk.org/pub/gtk/v2.8/win32/
Here you find (official I think) pre-compiled libraries, headers and
pkg-config files for Windows.
On Windows, I use a usual makefile (look at the patch in the sourceforge
page for makefile.mgw). Basically it uses pkg-config to add the good
flags.
>> All of the drawing API of cairo is independant of
>> the 'surface' where you are drawing to, you just have to care about the
>> surface creation itself, which may be a Windows HDC, a XDrawable (or a
>> GdkDrawable), or an offscreen surface (postcript, png, svg, or a raw
>> buffer).
>>
> Right, but if you have say a wxImage with alpha to draw or a wxBitmap
> what should one do to draw those?
Without alpha, you can build a so-called 'image' surface with the output
of wxImage::GetData(), being careful of the format (RGB for wxWidgets,
RGBA for Cairo or something like that).
I've not played with alpha, and it seems that you will lack a function to
get the alpha mask of a wxImage (but I may miss something).
>> As far as speed is concerned, I don't see much difference between GTK
>> and
>> Windows, and under some conditions it even seems faster on Windows. And,
>> needless to say, the rendering of the fonts is perfect under each
>> platform.
>>
> Does it already use OpenGL? This Amanith is doing that, only the licence
> does not fit. Only LGPL will do.
> Having a nice drawing context is great, but i found that currently
> alpha usage in wx is a problem to draw quickly.
You can use Glitz to render with OpenGL (I have not tried it). It means a
separate 'surface' again, but should work with X11 (glx) and Windows
(wgl).
>
> In any case its the best choice as far as i can see.
I agree.
>
> regards,
>
> Klaas
>
Best regards,
Timothée
Robert Roebling
>
> The speed is a concern, and I'm not sure that the MSW back
> end is a priority for the Cairo team.
I believe it is a concern.
> But an even bigger concern for me is the dependencies - using
> cairo to do our drawing on all platforms means a
> signfigant set of extra libs on Windows. We need cairo itself, of
> course, and pango for text layout, which means glib, which means iconv
> and gettext.
We might (no idea how easily) remove dependecies if they
provide functionality which we don't need.
> I'm not sure how good the Pango/win32 font support is
> either, so it might also mean Freetype and fontconfig.
It doesn't, since Pango has a Win32 Uniscribe and a
MacOS X ATSUI backend.
> I'd love to have a consistent, powerful vector drawing API
> on all platforms, but I'm a little worried about it being
> Cairo. Sadly, I don't have any other suggestions
Well, I will stick to Cairo in that case :-)
> If we wanted to take this route I'd suggest a
> wxCairoDC/wxGDIPlusDC/wxQuartzDC instead of a new API.
We might offer users direct access to the native
APIs (that is possible already now, but maybe not
easily enough), but it is needless to say that also
offering a common API is important, even if not
all backends are as fast as one might dream about.
> I think it's critical that we maintain our existing
> wxDC implementions,
I did not suggest to remove wxDC.
Robert