Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Sun, 2005-06-12 at 22:53 -0400, Morten Welinder wrote: > > > For non-local servers without Render, Cairo will allow us to eliminate > > the round-trips... a huge win. > > "Show me the money!" > > Back in the real world, new code goes in and someone files a performance > bug. Then you, Owen, seem to take that as a personal insult and close > it as NOTABUG or WONTFIX. > > Exhibit 1: bug 94718. A clear, to-the-point bug report that something > (namely greying of toolbars) had gotten so much slower that it was a > problem. It still is. The bug was originally filed in useless form, I indicated as much. when it was reopened with more useful data, it was left open. The data in the bug report is still really not very good ... all the profiling data was done in the remote case, and may well be completely irrelevant if the actual time is spent in roundtrips to the server (I think it is). But with the test case, there's the possibility that someone could pick up the bug, get some better data and come up with a patch. > Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of > data, a situation that "less" handled well a decade or two ago. I > routinely use "less" on files larger than 1GB or with lines that are > thousands of characters wide. While you didn't actually close this bug > (we kept it under "Gnumeric") you seem to think I am outside what you > designed for, hence my "Hello World" poke. You clear have *no* idea what I'm saying in comment #7. Or you'd realize that looking at the performance of 'less' is completely irrelevant here. Fixed with character grids without complex text handling are inherently fast. That doesn't mean that it's easy to make GtkTextView just as fast on the same font and data. > Exhibit 3: bug 104683. General Pango performance with a patch that > at the time cut 70% of cpu usage for the all-ASCII case (such as > numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and > "futured" it once) as evidently Pango's performance cannot possibly > be problematic. Problems with this "patch": - The 70% timing was done with code paths that weren't used by almost anybody when you filed the bug report, and aren't even minimally supported today - The patch made assumptions [width(AB) = width(A) + width(B)] that were planned to be broken at the point you filed the bug report and have since been broken. - The patch was lots of completely unrelated things shuffled together, many without any real justification In terms of NOTABUG, that's clearly explained in the comments in bug report. When you analyze the bug report, it comes down "Pango is slower than Morten likes". It's slower than Owen likes as well. Having a bug open like that does nothing to make Pango better. I want bug reports to be specific to particular issues. I left it open eventually because I got tired of fighting the battle. > I am somehow reminded of the word "attitude" reading these old, but > still-open, bug reports. What I try to make very clear on performance bug reports is that: A) Reports of something being *slower* than some previous version of GTK+ is not, in itself an issue. Things get slower typically because we add interesting and important features. Something being slower is *only* a problem when it is a performance bottleneck. B) Bug reports should be about specific fixable items. A bug report complaining that Pango is slow is not specific enough to be useful. C) Random patches that "optimize" some function that doesn't show up on profiles and without any benchmark to show that that patch makes a difference will not be accepted. It is in fact pretty hard to get me to take a performance patch for Pango. This is not because I don't want to improve Pango performance, it's because I've spent weeks and months working on Pango performance, so if a patch was easy to come up with, it's most likely either close to irrelevant or incorrect. There certainly are some areas where things could be improved (and some patches in Bugzilla to do so, especially for Arabic/Indic shaping), but we're talking mostly a few percent speedups. With a well-written ASCII-only codepath and programmatic options to degrade layout quality for speed, you might manage to get a 50% speedup for text *layout*. But Gnumeric cares most about text *rendering* speed, and with the X servers most people are running currently, speeding up text *layout* 50% will speed up rendering maybe 10%. > > Rendering speed is 90% an X server issue. > > I would normally define rendering speed as a measure of how fast you get > your pixels on the screen. With that definition in mind, look at bugs > 94718 and 104683 above and see that getting pixels on the screen got > much slower with constant X server. The toolkit is much, much more > than 10%. Rendering *DIFFERENT THINGS*. Yes, rendering alpha-composited images on a remote sever without the RENDER extension is sl
OT historical background [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/12/05, Jeff Waugh <[EMAIL PROTECTED]> wrote: > > > > > For non-local servers without Render, Cairo will allow us to eliminate > > > the round-trips... a huge win. > > > > "Show me the money!" > > Morten, I can understand your frustration, but to abuse some more movie > quotes: Your tone was pretty bogus, and we should all be excellent to each > other, regardless of any day-to-day hacking gripes we may have. Ob. IMDB backgrounder link for those who inexplicably did not grow up in the 80s: http://www.imdb.com/title/tt0096928/quotes Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
> > For non-local servers without Render, Cairo will allow us to eliminate > > the round-trips... a huge win. > > "Show me the money!" Morten, I can understand your frustration, but to abuse some more movie quotes: Your tone was pretty bogus, and we should all be excellent to each other, regardless of any day-to-day hacking gripes we may have. I've always found that positive reinforcement and encouragement goes a lot further than snide remarks (having tried both!), and it's our positivity that will bring new developers into - and hopefully stay in - our community. Thanks, - Jeff -- OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/ "It's never been, 'We're doing this for the good of society.' It's always been us taking an intellectual pride in putting out a good product - and making money. If putting a computer on every desktop and in every home didn't make money, we wouldn't do it." - Microserfs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: tinderbox-y status-y thing-y
On 6/12/05, Luis Villa <[EMAIL PROTECTED]> wrote: > * the nss install stuff is still sort of hosed when building against > firefox, but I have a patch: see > http://bugzilla.gnome.org/show_bug.cgi?id=154213 I should add that I'd greatly appreciate it if a couple other people could apply this patch and test it; see also the comment: http://bugzilla.gnome.org/show_bug.cgi?id=154213#c16 and the one-line change therein. thanks in advance for the testing- Luis (not an engineer, no matter what lies dave camp may tell you) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
tinderbox-y status-y thing-y
So since I've been whining about building gtk 2.7 and stack, and of course had only attempted a couple times to build it (and all had failed) I thought I'd poke at tinderbox-y bits this weekend. Some Luis Network News-y[1] bits: * the nss install stuff is still sort of hosed when building against firefox, but I have a patch: see http://bugzilla.gnome.org/show_bug.cgi?id=154213 * looks like even if that bug is fixed, e-d-s will fail to build: http://bugzilla.gnome.org/show_bug.cgi?id=307418 * if e-d-s fails to build, well, lots of things aren't so happy: http://tieguy.org/misc/temp-tinderbox-dump/ So that about covers the code front- until we get the nss and e-d-s stuff sorted out I'm sort of at an impasse on making tinderbox go further.[2] On the non-immediate-building-things front: * it is quite likely that I need a new physical box for tinderbox; I've gotten no response from the last two potential hosts so if anyone can donate a new box (and potentially hosting, I have no idea if gnome sysadmins are ready for that or not though :) please let me know. * I'm still hoping to integrate LDTP soon, but it's on the back burner for me personally. If someone (either from LDTP or otherwise) wants to look at it, that would rock. * if you're interested in other ways to help, poke at: http://live.gnome.org/MicroTinder_2fToDo Luis (building, building away) [1] Now even less unbiased! [2] I'm doing another run with docbook2xman installed, so that'll fix yelp and some other bits. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patch Pending: Tray icon does not account for icon transparency mask
On 6/12/05, Mike Hearn <[EMAIL PROTECTED]> wrote: > On Sat, 11 Jun 2005 18:36:23 +0300, Ilya Konstantinov wrote: > > So why wasn't my work merged into libegg? Only because nobody spent the > > time to understand the issue like I did? That's understandable, but why is > > the maintainer leaving me feeling as if my work was a waste? > > I wrote a patch to make the tray icon gently pulse on and off. I don't > remember if it's in bugzilla or not, but if it is I don't think it was > ever merged. I never emailed it anywhere because I don't know who > (if anyone) maintains libegg. I think we could help improve the situation for this particular issue by doing the following: implementing the auto-detecting and marking of unmaintained/under-maintained modules (manual setting of maintained-ness at developer request would also be allowed) and having show_bug.cgi provide a large warning when showing a bug in any such module. Further, the warning would contain a link to a wiki page on live.gnome.org that explains more about the status of such modules and hopefully provides contacts or dates on when the maintainer may return or whatever else might be helpful. Naturally, the wiki won't necessarily be kept immediately up to date (and the wiki would warn about that), but I think this would work well for any module that undergoes a longer period of being unmaintained/under-maintained (which we have a fair number of). This has been on my TODO list for a little while, but since Olav is actively working on upgrading bugzilla right now, this will be part of the upgrade instead. If anyone has any other ideas on how to make patch-review easier for maintainers and how to make it easier for contributors to understand the status and find potential ways they can help, please let us know. We've recently done a few things to help here (Olav will be mentioning one soon), and have a few other plans in mind, but extra ideas are always welcome. Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
building GNOME 2.11 on x86_64 using jhbuild
Hi,
In the last couple of days i've built gnome-2.11 using jhbuild about
10 times so far. It builds fine (uncovered some gcc4-related bugs,
filed them and they're fixed; apply a hal patch to n-c-b etc.). This
is on a Fedora system, with up-to-date packages from rawhide.
However, after it has finished building and you look at which
libraries the binaries are linked to, most of them are linked to
/usr/lib64 libraries instead of /home/jeroen/Gnome/built/lib64. I've
tried *lots* of things, but nothing helped. LD_LIBRARY_PATH is
pointing to /home/jeroen/Gnome/built/lib64. I even went as far as to
strace gnome-about and it *doesn't even look* in
/home/jeroen/Gnome/built/lib64:
$ echo $LD_LIBRARY_PATH
/home/jeroen/Gnome/built/lib64
$ strace gnome-about 2>&1 | less
execve("/home/jeroen/Gnome/built/bin/gnome-about", ["gnome-about"], [/* 44 vars
*/]) = 0
brk(0) = 0x509000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaab000
uname({sys="Linux", node="anduril", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/x86_64/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib64/tls/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/x86_64/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib64/libgnomeui-2.so.0", O_RDONLY) = 3
If my experience with jhbuild on x86_64 is anything like other people,
GNOME 2.12 will see *very* little testing on x86_64. I'm a developer
and i can't even get it to work...
Help?
Jeroen
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patch Pending: Tray icon does not account for icon transparency mask
On Sat, 11 Jun 2005 18:36:23 +0300, Ilya Konstantinov wrote: > So why wasn't my work merged into libegg? Only because nobody spent the > time to understand the issue like I did? That's understandable, but why is > the maintainer leaving me feeling as if my work was a waste? I wrote a patch to make the tray icon gently pulse on and off. I don't remember if it's in bugzilla or not, but if it is I don't think it was ever merged. I never emailed it anywhere because I don't know who (if anyone) maintains libegg. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
