Hi,
On Fri, Sep 3, 2010 at 12:59 AM, Matthias Clasen
wrote:
> On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote:
>
>> I was thinking about the problem of wasting memory, writing to one
>> internal representation and not changing the other, etc. How about
>> this: we only keep one representa
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote:
> I was thinking about the problem of wasting memory, writing to one
> internal representation and not changing the other, etc. How about
> this: we only keep one representation around. If you get_pixels we
> drop the surface, if you get_cai
Hi,
On Thu, Sep 2, 2010 at 11:21 PM, Andrew Cowie
wrote:
> Are you thinking of the loaders populating an image surface (and thus
> being in application memory) or populating an xlib surface (and thus
> being in X server memory?)
I'm not proposing any change here. Loaders currently go to pixbufs
On Thu, 2010-09-02 at 13:29 -0400, Havoc Pennington wrote:
> Each pixbuf could keep a cairo_surface_t which just pointed to the
> pixbuf pixels and that cairo_surface_t would be used in paint() or for
> other compositing/scaling/etc. kind of operations.
Are you thinking of the loaders populating a
Hi,
On Thu, Sep 2, 2010 at 6:14 PM, Matthias Clasen
wrote:
> Of course, this only handles the size_request side of things.
> It would be up to individual containers to respect the h/v-align in
> their size_allocate (basically replacing their current child
> properties), correct ?
Couldn't we do
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote:
> Hi,
> Am I missing a big downside?
One downside that you've mentioned earlier is that with this approach,
gdk-pixbuf grows a cairo (and thus libX11) dependency.
That might inconvenience a few gdk-pixbuf users. But the one I know
offhand,
On Sep 1, 2010, at 7:53 PM, John Ralls wrote:
>
> On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote:
>
>> On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote:
>>> It's now on Sourceforge because when Richard decided with his partner
>>> wind up Imendio and to withdraw from Gtk+, he asked o
Hi,
On Thu, Sep 2, 2010 at 5:07 PM, Matthias Clasen
wrote:
> One thing I wonder about though: one of the big reasons to keep
> GdkPixbuf around is the image loaders. But in this scheme, every
> pixbuf thats loaded from a file would end up with an old-style
> internal representation, right ?
>
Lo
On Thu, Sep 2, 2010 at 12:50 PM, Havoc Pennington
>
> Implementation-wise, I'm kind of leaning toward this, plus
> virtualizing "get the extra padding for request" and "remove the extra
> padding for allocation" and calling those virtual methods from the
> wrappers.
>
> So in this world, GtkSizeRe
On Thu, Sep 2, 2010 at 3:52 PM, Havoc Pennington wrote:
> Hi,
>
> I thought of another approach to this problem. Don't expose the pixbuf
> format at all; keep it as-is. However, add:
>
> gdk_pixbuf_get_cairo_surface()
> gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface);
>
> Now, keep t
Hi,
I thought of another approach to this problem. Don't expose the pixbuf
format at all; keep it as-is. However, add:
gdk_pixbuf_get_cairo_surface()
gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface);
Now, keep the cairo surface internally, strong-ref'd by the pixbuf.
The pixbuf woul
Hi,
On Thu, Sep 2, 2010 at 2:05 PM, Matthias Clasen
wrote:
> There is some move to cairo surfaces in Benjamins rendering-cleanup
> branch (replacing pixmaps with surfaces in some places).
Replacing pixmaps seems right to me (because cairo_surface_t is
basically replacing GdkDrawable). But pixbuf
On Thu, Sep 2, 2010 at 1:29 PM, Havoc Pennington wrote:
> On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen
> wrote:
>> Thanks for diving into this.
>>
>> As a datapoint, here is the current GTK/GDK api that directly involves
>> GdkPixbuf:
>>
>
> Cool, thanks. In a quick grep, basically nothing has
On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen
wrote:
> Thanks for diving into this.
>
> As a datapoint, here is the current GTK/GDK api that directly involves
> GdkPixbuf:
>
Cool, thanks. In a quick grep, basically nothing has been changed to
pass around cairo_surface_t as a representation of "
Hi,
2010/9/2 Krzysztof Kosiński :
> The functions are unnecessarily general. Only two functions are
> needed: an in-place conversion of an entire pixbuf, and duplication
> with conversion (to cover cases where the number of bytes per pixel is
> different, or lossy conversion). There's no need to s
Thanks for diving into this.
As a datapoint, here is the current GTK/GDK api that directly involves
GdkPixbuf:
gtk_about_dialog_get_logo
gtk_about_dialog_set_logo
gtk_assistant_set_page_header_image
gtk_assistant_get_page_header_image
GtkCellRendererPixbuf::pixbuf
GtkCellRendererPixbuf::pixbuf-ex
Hi,
On Sun, Aug 29, 2010 at 7:02 PM, Havoc Pennington wrote:
>
> - one approach: put padding stuff in the size_request / size_allocate
> *wrappers* in the same way that size groups and set_size_request are
> handled. all widgets just work without modifications, is the big plus
> of this.
>
Imple
2010/9/2 Havoc Pennington :
> See bugs:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=395578
> https://bugzilla.gnome.org/show_bug.cgi?id=491507
>
> I'm attaching a patch which proposes some API to make GdkPixbuf
> support the cairo RGB24/ARGB32 formats.
> In this patch, there's no actual code to
I have now committed a first round of cleanups to master (and
corresponding deprectations to 2.22).
In detail,
> 1) GtkDialog::has-separator
> GtkMessageDialog::use-separator
These are gone.
> 2) GtkStatusIcon::blinking
Gone.
> 3) GtkIconView::orientation
> GtkCellRendererProgress::orie
On Thu, Sep 2, 2010 at 10:35 AM, Havoc Pennington wrote:
> Does anyone have any opinions on the main idea here, i.e. move padding
> to GtkWidget instead of putting it in every container (and GtkMisc)?
I haven't looked at it in detail yet, but the gut feeling is 'hell
yes, anything that reigns in
Does anyone have any opinions on the main idea here, i.e. move padding
to GtkWidget instead of putting it in every container (and GtkMisc)?
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-li
Hi,
On Thu, Sep 2, 2010 at 5:38 AM, Tristan Van Berkom
wrote:
> On the other hand... since g_object_new() will never return NULL...
> I'm not sure how much this api would be different than simply
> invoking these lines of code:
>
> gtk_container_add_with_properties (container,
>
On Wed, 2010-09-01 at 10:59 -0400, Havoc Pennington wrote:
> Hi,
>
> On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom
> wrote:
> > I like this idea alot and as its a trivial patch I might write one
> > up tonight or tomorrow ...
>
> well, it's trivial except for the need to add some kind of go
23 matches
Mail list logo
