Re: Plans for drawing in GDK-1.4.

[Owen Taylor <otaylor redhat com>]

Elliott Hughes <Elliott.Hughes@genedata.com> writes:

> Alexander Piskunov <sd90034@lanet.lv> wrote:
> > This is what I always wanted to see in GTK+.
> > Today opaque resize is completely unusable on my Pentium 120, S3 V+, but
> > when I switch to Win95, difference is _very_ noticeable. I don't know if
> > Win9x toolkit uses backing pixmap, but opaque resize is _much_ faster.
> > The same goes for expose/redraw events.
> > So using offscreen drawing is definitely a very good idea:)
> 
> i'm not sure this is the reason. a lot of Windows stuff i've seen doesn't
> actually resize the contents of the window until the user finishes resizing
> the window frame.
> 
> whatever, low-level support for double-buffered drawing is long overdue.
> the change to gint coordinates makes sense too. from my point of view,
> the scrolling changes are less of a priority, and problems there should be
> ameliorated at least in part by double-buffering.

How does this help? Double buffering wouldn't decrease the amount
of time until the newly scrolled-in areas are updated as far
as I can see.
 
> i'm not sure i'd have the two suggested routines, though. why not have
> this done by default, with a flag to turn it off, rather than make it
> necessary for people to explicitly use double-buffering?

Well, I don't really see how to do this. You would need an "end_paint"
in any case to know when to copy the back-buffer onto the window;
and besides that you would have to track the changed regions or
copy the whole pixmap every time. And also, the begin_paint / end_paint
saves memory since you don't have to always keep a backing-pixmap
for each window around.

At the widget level double-buffering will appear to be automatic,
since GTK+ will do the begin_paint / end_paint around handling
an expose event.
 
> on the subject of scrolling, will the set_scroll_adjustments stuff go into
> GtkWidget? that would be nice.

Just because there is a scroll-window call doesn't mean that scrolling
is generic. A widget would have to keep track of the coordinate
offsets. Also, scrolleable widgets will want to be able to do things
like GtkCList which scrolls the titles horizontally, but not
vertically.

The whole point of not putting set_scroll_adjustments into GtkWidget
was to avoid bloating the GtkWidget interface with yet more signals.

Adding support for interfaces to GtkObject is still in the plans
for 1.4, and set_scroll_adjustments is a prime target for making
an interface.

Regards,
                                        Owen