Would there be any possibility that someone who knows OpenGL coding and GtkGLExt would make additions to this so it can be used with Cairo+glitz+GtkGLExt do use OpenGL for rendering the canvas?I would be terribly great if someone did that, i'm stabbing at it myself but i'm almost no OpenGL coder an
On 12/5/05, Damon Chaplin <[EMAIL PROTECTED]> wrote:
> I've also read the SVG spec (http://www.w3.org/TR/SVG11/), which is very
> interesting. I wonder if we'll want an SVG widget in GTK+ at some point,
> and if so, will we want a separate canvas as well? I guess it makes
> sense to try to use the
On Sat, 2005-12-03 at 03:28 +0100, milosz derezynski wrote:
> http://beep-media-player.org/~mderezynski/cairo.txt
Fantastic. I've started adding DocBook markup to this, and will commit
it to the GTK+ docs when I'm done with that.
Milosz, if you make changes to your text, could you please forwar
I've put goocanvas 0.2 (my cairo canvas widget) up at:
http://www.dachaplin.dsl.pipex.com/goocanvas/
New features:
o affine transformations for all items.
o event handling, including support for pointer grabs.
o support for simple animation.
o finished port of FooCanvas demo, and added test
On Mon, 5 Dec 2005, Morten Welinder wrote:
It sounds to me that you had two pieces of code that sucked: the
glib mempools and the glibc malloc.
glibc malloc is actually pretty good, i don't think it sucks for what
it does. it's mallocs on many other platforms that can suck, and in
some cases
> GStreamer uses GLib and is highly multi-threaded. These mempools were
> showing up high in my benchmarks when I was profiling GStreamer's
> overhead. Pushing this threadsafe pooling down to GLib gets it out of
> Gnumeric, evolution, gstreamer, etc. Maybe one day it can make it into
> glibc it
Just to put some things in perspective for a moment, I can give a few reasons
why I'd support the g_slice implementation. I am definetely not the common glib
use case, but it does go to show that the library is used in many different
ways.
1) The performance is better than memchunks, which is a
Hi Morten,
I'll bite.
On Mon, 2005-12-05 at 10:44 -0500, Morten Welinder wrote:
> Which brings me to... What data structures in glib programs (existing
> and predicted in the next few years) are (a) used multi-threaded, and
> (b) used often enough to warrant performance considerations?
I trust
It sounds to me that you had two pieces of code that sucked: the
glib mempools and the glibc malloc.
Well known. Both Gnumeric and Evolution wrote their own specialized
pool allocators because of that. (Why two? Because we didn't know
about each other.)
I don't think I should compare slices t
On Sat, 3 Dec 2005, Morten Welinder wrote:
I might be dense, but what exactly does g_slice_ buy us over
plain, old malloc?
* Don't say speed. That's a bogus argument because you cannot
possibly have tested all mallocs.
speed. simply because for some (glibc) tested mallocs, g_slice is
faste
On Sat, 3 Dec 2005, Dave Benson wrote:
On Sat, Dec 03, 2005 at 10:35:38PM -0500, Behdad Esfahbod wrote:
On Sat, 3 Dec 2005, Morten Welinder wrote:
I might be dense, but what exactly does g_slice_ buy us over
plain, old malloc?
* Don't say speed. That's a bogus argument because you cannot
11 matches
Mail list logo
