Meeting on irc.gnome.org:#gtk-devel
Meeting started October 25 2004 17:03 EST (21:03 UTC)

In attendence: 

Owen Taylor (owen), Jonathan Blandford (jrb_sick), Manish Singh (yosh),
Matthias Clasen (matthias), Federico Mena Quintero (federico_), 
John Ehresman (jpe), Ray Strode (halfline), Robert Ögren (roboros), 
Maciej Katafiasz (mathrick), James Cape (Jimbob), Morten Welinder (gmorten),
Anders Carlsson (andersca), Carlos Garnacho Parro (garnacho)


<matthias>	any agenda items for today ?
<vektor>	I'd like to ping on one of my bugs, but I don't know if it's meeting worthy.
<matthias>	sure
<vektor>	144729, is it a breaking change?
<owen>	vektor: Yes
<vektor>	OK, should I do a patch which adds API?
<owen>	vektor: I think you should think about how to fix the performance problem without adding HINT mask. HINT mask is a fundementally screwed up idea.
<owen>	Of course, it's easy on the programmer, so that's something to be said for it....
<vektor>	Well, in general there are lots of cases where the hint is useful, any time you have an event handler that can take a long time.
<vektor>	Usually you don't want _all_ mouse events, like it seems to me that the hint should be the default for most everything.
<vektor>	Otherwise you're just asking to do more work.
<owen>	vektor: Well, the golden rule is that event handlers should take close to zero time and queue anything that is slow 
<matthias>	isn't that basically the problem: event handlers which take a long time
<vektor>	Well, often you don't know that an operation will take a long time.
<vektor>	Interactive resizing is a good example.
<owen>	vektor: HINT mask is evil because it forces server round trips. And also evil because it requires apps to write for it specifically
<vektor>	If you're resizing something based on mouse events, it could cause a lot of work to happen.
<vektor>	All we do in this mouse handler is set the selected item in the treeview, so the performance problem in this particular case is probably something in GTK+...
<owen>	vektor: You can do event compression better client side.
<owen>	vektor: You aren't reacting to the selected item? 
<andersca>	vektor: there's the "hover_select" property in 2.5 or 2.4, can't remember
<vektor>	I don't think so ...
<matthias>	vektor: do you have a C-only testcase ? 
<owen>	vektor: How big is the tree view? GTK+ is pretty religious about queueig resizes and so forth, so I wouldn't expect trailed lagging 
<vektor>	matthias: I'll code one up, shouldn't be hard ...
<owen>	vektor: That is, it might be slow, but you shouldn't see it get farther and farther behind
<matthias>	vektor: as andersca points out, the treeview in 2.6 has a mode to let the selection follow the mouse, and it doesn't seem to suffer from performance problems
<owen>	(And changing the selected item a few dozen times a second shouldn't even be slow)
<gmorten>	the treeview is well known for sending cpu load through the roof.
<vektor>	It seems to happen best right when the window is shown, so there are lots of other events in the queue.
<gmorten>	when you move the mouse, that is.
<jrb_sick>	gmorten: it shouldn't send it through the roof
<owen>	gmorten: Well, that's the prelight. But eating cpu isn't the same as lagging.
<gmorten>	jrb_sick: well, anything you mouse over gets re-fetched from the model, re-rendered, etc.  Even though no pixels change.
<mathrick>	jrb_sick: it takes >10% on athlon 2k
<mathrick>	just moving the mouse over it
<andersca>	takes 4% on an 800mhz pentium 3
<jrb_sick>	sounds high
<mathrick>	that's with no prelight actually taking place, I should add
<jrb_sick>	mathrick: it's up to the renderers to prelight if they want
<mathrick>	jrb_sick: yeah, I know, but point is, no computation is done to prelight anything, just checking for prelight eats 10% CPU
<federico_>	just profile the thing
<owen>	mathrick: It just queues a redraw on the rows always
<jrb_sick>	mclasen: prelighting in GtkTreeView isn't the only thing on the agenda, right?
<owen>	mathrick: There is no cell renderer flag "I'm really going to draw prelighted"
Oct 25 17:20:10 *	jrb_sick still doesn't buy the 10% usage
<matthias>	jrb_sick: I wanted to talk to tml about the status of his win32 filename encoding patch, but he isn't here...
<mathrick>	owen: ah, that explaing, but that's not totally optimal thing to do, as it's more common not to prelight
<gmorten>	10%+ here
<mathrick>	s/ng/ns/
<matthias>	jrb_sick: other than that, I have no urgent agenda items.
<owen>	mathrick: Well, no, it's not the totallly optimal thing to do ...
<owen>	mathrick: It was desinged to be the simplest thing to do
<owen>	gmorten: How many columns?
<owen>	(And early versions of GtkTreeView prelighted everything)
<gmorten>	owen: a filechooser
<gmorten>	on a sparc on unknown speed
<mathrick>	owen: ic, would it be possible to optimize that redraw away in cell renderer if needed?
<owen>	sparc of unknown speed == slow (per cpu anyways, add enough cpu and the box might be distinctly not slow. But that doesn't help a single thread)
<gmorten>	undoubtedly not impressive speed by modern standards.
<gmorten>	buy hey, it has 96G memory...
<andersca>	let's just store all different cell types in memory then ;)
<owen>	mathrick: We could a "this cell renderer doesn't prelight" flag compatibly. Though we might still be changing the GtkState for drawing ... so it might be up to the theme, which would be harder to optimize. I forget
<mathrick>	gmorten: wow, 96GB is something to reckon with :)
<mathrick>	owen: ic, so in current GTK+ there would be no way to write smart renderer able to avoid that redrawing?
<owen>	mathrick: Yeah, the renderer doesn't know why it was asked to redraw
<matthias>	ok, let me give a quick update on reaching the "slush frozen" status: in the last week, we got the key file parser, the named icons in images and about dialogs, the clipboard persistence and image/file dnd convenience api committed. 
<matthias>	I'll commit the hig dialog patch tomorrow, and I would love to get tmls filename encoding patch in glib. after that, I'll start rolling 2.5.4
<andersca>	great
<andersca>	would it be possible to get image convenience functions for gtkclipboard in before 2.6?
<matthias>	andersca: I was about to list what I see as candidates for breaking the slush freeze...
<gmorten>	matthias: g_ascii_strtod needs life support.
<matthias>	we seem to have some api-adding patches almost ready: I think Jimbob has a large filechooserbutton patch which adds some api for controlling the width of ellipsised labels, 
<federico_>	mathrick: see if do_prelight() is queueing a draw for each mouse movement; it should do it only if the last prelighted node is not equal to the current node
<jrb_sick>	federico_: it should behave that way
<federico_>	jrb_sick: it looks like it does; but I'm not sure if it in fact is :)
<matthias>	gmorten: you'll do the CPR
<jrb_sick>	matthias: we should also get seth to look at the two odd use cases for GtkFilechooserButton
<matthias>	?
<gmorten>	matthias: or just take the thing out back and shoot it...
<gmorten>	anyway, time for kids
<jrb_sick>	federico_: it did when I wrote it...
<federico_>	can we backport the typeahead patches to 2.4?
<matthias>	jrb_sick: I'm not sure if there is much to do about it; they're just odd, but nobody is forced to use them. We can document them as odd...
<matthias>	(continuing the list of freeze break candidates)andersca mentioned convenience api for image cnp in GtkClipboard which should be very easy to add now, halfline has some additions for GKeyFile (comments)
<federico_>	there's anders's api to add pixbuf formats to a gtkfilefilter
<jrb_sick>	matthias: for starters, we can limit the entry to just display the filename
<matthias>	anything else ? We do have a huge number of bugs on the 2.6 API freeze milestones (130 in GTK+, 30 in GLib), and should probably start to triage that list 
<matthias>	federico_: is there anything keeping that from being committed ?
<jrb_sick>	matthias: it's a big change for the stable branch
<matthias>	jrb_sick: ? you're talking about backporting typeahead, right ? I was referring to the pixbuf formats for filefilter patch, which is head-only...
<federico_>	matthias: not that I know of... andersca?
<andersca>	nope, should work
<jrb_sick>	oh,  yeah.  I lost track of the topic of conversation..
<matthias>	one thing I wanted to mention is that I took the liberty to commit my button order patch. So we can switch to an alternative button order by changing a setting now 
Oct 25 17:45:06 *	jrb_sick grumps
Oct 25 17:45:22 *	andersca too
<owen>	Note that patches to suppor talternative button order should be rejected for gnome applications
<owen>	(That is, applications liek gnome-panel, not applications that are meant to conform to gnome guidelines in genreal)
<matthias>	well, it is meant to help apps which want to achieve a native appearance on other platforms, so it doesn't mean that gnome should offer a button order switch
<owen>	matthias: Exactly.
<matthias>	It will work out of the box for all builtin GTK+ dialogs and for GtkMessageDialogs. Apps will have to take care of the rest
<matthias>	So, while it may be a controversial feature it certainly fits with the "improve win32 integration" theme which we have followed with a number of other 2.6 features...
<federico_>	my god, matthias is a goneme killer
<matthias>	speaking about win32 integration, one thing which I thought about earlier today is that we should check whether there are any important fixes for the windows theme engine and input method from their authors
<owen> Note that patches to suppor talternative button order should be rejected for gnome applications
<matthias>	federico_: maybe it will give them new energy, who knows
<federico_>	jrb_sick: 150949 is fixed in HEAD, right?
<jrb_sick>	yeah
<matthias>	did we switch to prefix matching ?
<jrb_sick>	matthias: yup
<federico_>	cool
<federico_>	matthias: do you know if 152330 is still valid?
<federico_>	(I'm building HEAD at the moment, so can't really test it right now...)
<matthias>	federico_: should still be valid. I haven't started to fix the issues with changing the tree underneath a combobox yet
<federico_>	matthias: ok
<federico_>	I'm trying to see if there are must-fix bugs in the file chooser before I start doing some usability stuff on it
<jrb_sick>	federico_: "usability stuff"?
<matthias>	fedrico_: one filechooser nasty is that size allocation loop if the file chooser widget is not given enough space for the paned
<federico_>	jrb_sick: alt-number for the bookmarks, some keynav enhancements, etc.
<federico_>	jrb_sick: I want the "it doesn't have an entry" complaints to stop
<federico_>	matthias: ah, yes, that's definitely one to fix
<federico_>	in theory just taking out that _set_size_request() for the shortcuts pane and letting it auto-size should work, right?
<matthias>	federico_: some things which would probably improve the usability a great deal require some lower-level work, e.g. we need tooltips on treeviews, and a way to hide the text in the add/remove buttons to allow the bookmarks list to be not so wide
<federico_>	matthias: we can probably steal gaim's code for tooltips-on-treeviews for now...
<federico_>	owen: did you have some ideas on how select-folder should work?
<andersca>	jrb is working on tooltips-on-treeviews
<matthias>	ooh, he is ?! so *that* is his secret project ...
<federico_>	nice!
<owen>	federico_: select folder?
<federico_>	owen: maybe I misremember, but you know how double clicking on a folder in GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER takes you to *that* folder rather than activating it, etc.
<federico_>	owen: I think you were talking about that at some point
Oct 25 18:14:13 *	federico_ may be confused
<matthias>	federico: with tooltips on treeviews, we can also allow users to name bookmarks, and show the full path in a tooltip
<matthias>	federico: I did some changes to the select-folder logic some time ago. I think it is reasonable now, maybe you should try it again
<federico_>	matthias: ok, I'll test them
<matthias>	anyway, the kids are coming home any minute now, I have to quit
<matthias>	I'll put the logs up tomorrow. See you
<federico_>	see you, matthias


Meeting ended October 19, 18:16 EST (22:16 UTC)