On Mon, 14 Feb 2011 20:32:48 +0100
Benjamin Otte wrote:
> For now, I'm interested in high-level review of the idea. Things like
> "This whole idea is stupid because ...", "I would change the API so
> that ...", "If you did this, we could also use it for ...", "How do
> you intend to solve ..." or
that implies keeping all svg data around (+
probably pixels for fast rendering). Perhaps something like that is
better done at load time, or at least make saving the data optional?
> I thought a bit about allowing unsized pictures, but it didn't make
> sense to me. First, from looking at the
ral one. I'm probably also
gonna at a ResizablePicture interface and implement it in the SVG
loader so that you can live-resize an SVG that you loaded.
I thought a bit about allowing unsized pictures, but it didn't make
sense to me. First, from looking at the librsvg API, it seemed to me
that
On Mon, 2011-02-14 at 20:32 +0100, Benjamin Otte wrote:
> The header defining GdkPicture can be found at
> http://git.gnome.org/browse/gtk+/tree/gdk/gdkpicture.h?h=picture
> It will tell you that a picture has
> - a size (width and height)
> - a way to draw it to a cairo context
> - a way to tell y
;re used to think of
images as one of those two examples.
> - How does this relate to cairo surfaces ? If pictures are the one
> true way to pass pixel
> data to gtk, do we need a picture that wraps cairo surfaces ?
>
Well, a picture that wraps a cairo surface is basically ju
belong in gdk ?
- It seems to be somewhat stuck in an uncomfortable place between a 'dumb pixel
area' (GdkPixbuf) and a 'smart active image' (resizable, possibly
animated, draws itself)
- How does this relate to cairo surfaces ? If pictures are the one
true way to pa
implement optimizations (you are for example free to store your
data as a GL texture if that makes things go faster) and be a lot more
flexible (you could have a subclass that does not store any pixels but
actually renders text).
2) It can change
By emitting signals whenever things change (both con
