Havoc Pennington wrote some notes about Canvas widgets http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html
Not sure if he is aware of Inkscape plans to share canvas widget. Someone interested in this area might want to talk to him or respond to that conversation on the gtk-devel list.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Mon, 2005-08-15 at 17:22 +0100, Alan Horkan wrote:
Havoc Pennington wrote some notes about Canvas widgets http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html
Not sure if he is aware of Inkscape plans to share canvas widget. Someone interested in this area might want to talk to him or respond to that conversation on the gtk-devel list.
We would need a canvas widget that doesn't suck, first.
If they can implement a decent canvas widget, more power to them. Then we could use it ourselves. Given that our canvas widget keeps getting worse (we don't even have proper tile cacheing anymore, IIRC), I don't think we'd be much help to them.
The part we would want to share would be "SVG canvas" bits, which could be built atop any decent canvas widget (though obviously we'll have to pick a specific one).
-mental
On 8/15/05, MenTaLguY <mental@...3...> wrote:
We would need a canvas widget that doesn't suck, first.
If they can implement a decent canvas widget, more power to them. Then we could use it ourselves. Given that our canvas widget keeps getting worse (we don't even have proper tile cacheing anymore, IIRC), I don't think we'd be much help to them.
The part we would want to share would be "SVG canvas" bits, which could be built atop any decent canvas widget (though obviously we'll have to pick a specific one).
Isn't Cairo been pushed to 1.0 for GNOME 2.12 release? This would mean quite stable API (but not neccesarily speed and robustness, though I'd like to be wrong).
Alexandre
On Mon, 2005-08-15 at 23:45 +0400, Alexandre Prokoudine wrote:
Isn't Cairo been pushed to 1.0 for GNOME 2.12 release? This would mean quite stable API (but not neccesarily speed and robustness, though I'd like to be wrong).
Non-sequitur. Cairo has nothing to do with canvas widgets directly; it's just a rendering API upon which a canvas widget might be implemented.
So I can answer this once for everybody, here's how things break down, comparing the Inkscape and (hypothetical) Cairo/GTK stack ... the list is from low-level to high-level, so each layer builds atop the previous ones:
Inkscape Cairo/GTK -------- --------- Compositing/Buffering: libnr libpixman Rendering: libnr+livarot cairo Retained-mode Canvas: SPCanvas+NRArena (hypothetical) GtkCanvas SVG Canvas: SPObject n/a
So, Cairo cannot replace SPCanvas. It doesn't supercede GtkCanvas, and nothing can replace SPObject. Any "bottom-up" slice of the Inkscape stack can (in principle) be replaced by any equivalent bottom-up slice of the Cairo/GTK one. e.g. we could replace libnr+livarot with libpixman+cairo.
And when we talk about sharing out an "SVG Canvas", we are really referring to SPObject, built atop whatever retained-mode API we choose. Could be GtkCanvas eventually, if it proved adequate for our needs.
-mental
Thank you for clarification!
Alexandre
On 8/16/05, MenTaLguY <mental@...3...> wrote:
On Mon, 2005-08-15 at 23:45 +0400, Alexandre Prokoudine wrote:
Isn't Cairo been pushed to 1.0 for GNOME 2.12 release? This would mean quite stable API (but not neccesarily speed and robustness, though I'd like to be wrong).
Non-sequitur. Cairo has nothing to do with canvas widgets directly; it's just a rendering API upon which a canvas widget might be implemented.
So I can answer this once for everybody, here's how things break down, comparing the Inkscape and (hypothetical) Cairo/GTK stack ... the list is from low-level to high-level, so each layer builds atop the previous ones:
Inkscape Cairo/GTK -------- ---------Compositing/Buffering: libnr libpixman Rendering: libnr+livarot cairo Retained-mode Canvas: SPCanvas+NRArena (hypothetical) GtkCanvas SVG Canvas: SPObject n/a
So, Cairo cannot replace SPCanvas. It doesn't supercede GtkCanvas, and nothing can replace SPObject. Any "bottom-up" slice of the Inkscape stack can (in principle) be replaced by any equivalent bottom-up slice of the Cairo/GTK one. e.g. we could replace libnr+livarot with libpixman+cairo.
And when we talk about sharing out an "SVG Canvas", we are really referring to SPObject, built atop whatever retained-mode API we choose. Could be GtkCanvas eventually, if it proved adequate for our needs.
-mental
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBDAS47cUNIGiXCc4MRAq5TAKDDGCWuccCd3r4wD0xED5PC8+hP0ACgmo4W MUcV/o9qBrwvBluqIAvagiA= =gepr -----END PGP SIGNATURE-----
thanks also for clearing that up mental
participants (4)
-
Alan Horkan -
Alexandre Prokoudine -
Andy Fitzsimon -
MenTaLguY