Re: efficient use of canvas lines
- From: Paul Davis <pbd Op Net>
- To: John Cupitt <john cupitt ng-london org uk>
- Cc: Ian Britten <britten caris com>, gtk-list gnome org
- Subject: Re: efficient use of canvas lines
- Date: Mon, 16 Jul 2001 15:09:56 -0400
In message <3B531874 5131BFF8 ng-london org uk>you write:
>Ian Britten wrote:
>> It's a similar case with the gtkpixbuf: I tried using it once on a
>> relatively small arial photo (50M). After it crashed X and hard-locked
>> the machine, I didn't try that again... :-(
>> [ FYI - +200M images aren't out of the realm of possibility... ]
>
>I believe gdkpixbuf, built into the upcoming gtk2, fixes at least some
>of this. You don't have to render the whole image, you can just do
>little bits on an expose or scroll.
Yes, but the pixbuf does have any nice methods to do
gdk_draw_foo()-style operations on it. See Havoc's book chapter for
his notes on this and how it affected guppi.
>I did my own imagedisplay widget :-) It's not too hard: just a
>GtkDrawingArea, a couple of GtkAdjustments, and some very simple stuff
>to map virtual to real coordinates for repainting. You can scroll/zoom
>on 800M images pretty well with it, and it has some simple support for
>image annotations too.
You can't use a GtkDrawingArea on the Canvas and expect it to work
correctly when other CanvasItems occupy the same space. Thats true for
all GtkWidgets, for that matter. They don't render to the Canvas, and
so they don't obey stacking order.
It would be a rather nice piece of work (GTK 2.1 or 3.0?) to modify
the entire widget model so that they could render either to their
widget->window, or the Canvas intermediate buffer.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]