[18:23] mozilla bug 413583 [18:23] ^^^ thats the corruption bug upstream [18:23] Mozilla bug 413583 in GFX "cairo xlib buggy_repeat not detected correctly" [Major,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=413583 [18:27] Ubulette: ^^^ [18:27] can you try the cairo patch in there? [18:27] (its a workaround afaik) [18:27] * asac has to run [18:28] http://ejohn.org/blog/sub-pixel-problems-in-css/ [18:28] red lines has beend duped btw [18:46] yep, read that too. [18:47] as for trying the patch, i can't at home (nvidia) but I can push it to my ppa [19:09] <[reed]> asac / Ubulette: seen mozilla bug 394103? how many people are seeing it [19:10] Mozilla bug 394103 in OS Integration "All elements are HUGE (when doing dpi autodetect?)" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=394103 [19:10] i don't but we have bugs and reports in the forum [19:10] [reed]: i looked in code yesterday [19:10] its for people that have a dpi higher than 143 [19:10] the fix is to force dpi 96 everywhere [19:11] i initially thought it was easy to fix, but then i found that the culprid is the image scaling [19:11] asac, http://www.sofaraway.org/ubuntu/debdiff/cairo_1.5.8-0ubuntu1--1.5.8-0ubuntu2.debdiff [19:11] you cannot scale images continously [19:11] <[reed]> can you comment in the bug and/or produce a patch? I can get it to be a blocker, but it needs an owner. [19:12] so you can either have 1:1 ... or 2:1 ... thats why you get the sudden boost in size of icons when crossing the 143 border [19:12] <[reed]> hmm [19:12] [reed]: yes. i can take that [19:12] <[reed]> ok, cool [19:12] 96+48 [19:12] <[reed]> so, what does the image scaling? [19:12] =144 [19:12] <[reed]> libpr0n? cairo? [19:12] <[reed]> layout? [19:12] [reed]: no its in thebes device context [19:12] gfx [19:12] <[reed]> ok, I'll move to GFX: Thebes [19:12] <[reed]> and renom for blocoking [19:13] <[reed]> blocking [19:13] <[reed]> and you can assign to yourself [19:13] http://lxr.mozilla.org/seamonkey/source/gfx/src/thebes/nsThebesDeviceContext.cpp#233 [19:14] asac, seems the kde team guys are daily building in their ppa [19:14] [reed]: try yourself ... set layout.css.dpi to 144 and you will instantly see what they see ;) [19:15] (those poor people that invested soo much in their monitor/laptop) :) [19:15] <[reed]> asac: ok, go assign the bug to yourself [19:15] <[reed]> I'll get it to be a blocker :) [19:16] "mid-air collission" :) with reed [19:16] <[reed]> hehe [19:17] taken [19:18] <[reed]> thx [19:19] [reed]: do you have a form thread at hand that complains about it? [19:20] <[reed]> forum* ? [19:20] <[reed]> if forum*, then no. Ubulette might, though [19:20] <[reed]> however, see the other bugs that have been duped [19:20] you wrote that there are lots of complains in the forms ;) [19:20] didn't you? [19:20] i would like to get a few testers in this channel that have such a screen [19:21] well 2 testers would be fine ;) [19:23] ask in the bug [19:24] Ubulette: let me now test the cairo patch [19:24] Ubulette: did you manage to use all hunks? [19:29] ok i see [19:30] pushed to my ppa for testers but it's crowded in there :P [19:32] <[reed]> i don't but we have bugs and reports in the forum [19:32] <[reed]> that's why I said that [19:32] <[reed]> :) [19:32] yep [19:36] Ubulette: works :) [19:36] wanna sponsor it ? :) [19:37] Ubulette: can you please test if scrolling the preview in wiki.ubuntu.com is slow as hell for you as well? [19:37] (without that patch) [19:37] i am not sure. vlad probably would have applied that patch if it was a good idea to do so [19:38] it's not [19:38] afaik they still hope to figure the real cause for that [19:38] Ubulette: maybe attach the patch to the bug for now, so we remember. we have it set to blocking beta [19:38] i will try to talk to him [19:38] well, we can still drop the patch if/when they really fix it, that's why i've said workaround instead of fix [19:39] let me try if scrolling is normal again after backing out this patch [19:39] Ubulette: maybe you can try if its slow for you with that patch as well? [19:45] [reed], what's a beta bandaid ? [19:45] <[reed]> wallpaper fix for beta [19:46] <[reed]> instead of the real fix [19:46] ? [19:46] <[reed]> umm, it means that it might fix the problem, but it's not the real fix [19:46] <[reed]> temporary fix [19:46] <[reed]> until the real issue can be found [19:46] <[reed]> but a fix needed for the beta [19:46] but it's committed anyway ? [19:46] <[reed]> dunno, check bonsai [19:47] yes it in b3 [19:48] asac, so there's no problem for us either [19:55] ok, built [23:47] bug 192198 [23:47] Launchpad bug 192198 in firefox-3.0 "rendering problem on firefox 3" [Undecided,New] https://launchpad.net/bugs/192198 [23:47] armin76, [reed], seen something like this ? ^^ [23:48] looks like the miro wrapping bug (miro built with xul 1.9) [23:48] <[reed]> yes [23:48] <[reed]> known bug [23:48] # ? [23:55] [reed], bug number ? [23:55] <[reed]> bugzilla is not responding [23:55] <[reed]> give me a sec :) [23:55] :) [23:56] bug 186771 [23:56] Launchpad bug 186771 in firefox-3.0 "use more GTK stock icons." [Low,Invalid] https://launchpad.net/bugs/186771 [23:56] [reed], ^^ what do you think ? [23:58] Ubulette: please don't invalidate bugs that need to be send upstream :) [23:58] <[reed]> invalid on your side... please send upstream [23:58] <[reed]> Firefox :: Theme [23:58] well, part of it is solved in b4pre [23:59] [reed]: well ... we should not close them _before_ they are send upstream. And even after sending them upstream we should keep them open. otherwise it will trigger dupes here.