Re: Plans for drawing in GDK-1.4.

[Elliott Hughes <Elliott Hughes genedata com>]

Owen Taylor <otaylor@redhat.com> wrote:
> 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.

no, but it will improve the appearance. as you note on your web page,
it's not speed that's the problem, it's perceived quality, and flicker plays
a large part in this perception.

> 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.

sorry, this is what i meant. i'd misunderstood you, and you misunderstood
my misunderstanding! this sounds fine.

> 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.

my contention is that scrolling is almost ubiquitous, particularly in
user-written widgets. there aren't many little widgets not already
available, so widget writers will almost certainly have to deal with
scrolling. i accept that they'll have to take the scroll offsets into
account, but i find it unfortunate that they have to write the
set_scroll_adjustments code each time.

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

how about in GtkDrawingArea then? because it actually has a window,
this tends to be more convenient for the widget writer than direct use of
GtkWidget.

> 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.

i just have the feeling that the current situation is less convenient than
it could be. i don't much mind how it gets resolved, as long as it does.

this is the reason that i find low-level support for double-buffering so
critical. relatively inexperienced Java programmers can produce
good-looking widgets with Swing because it automatically does the
double-buffering behind the scenes. even if they redraw their widget
slowly, it still has a certain gracefulness that even the best-written
GTK+ widgets lack at the moment. the first thing that Java programmers
notice about GTK+ is how badly ir flickers.

i think one of the reasons for the failure of Xt was the belief that writing
widgets was hard, for experts, and not something that should be par for
the course when writing a GUI program. failure? compare with what we
see done with Java's toolkit, where writing one's own widget _is_ seen
as easy, and _is_ seen as a normal, reasonable part of the development
process for just about any program of any interest. (i.e. not just another
bleedin' IRC client.)

-- 
"As the Chinese say, 1001 words is worth more than a picture."
	-- John McCarthy