This is a total non-expert opinion, but aren't we scaling all of the images to correct for the high-dpi screen? That sounds like it would call for bilinear filtering.
owen On Tue, 2007-03-13 at 11:52 -0400, Adam Jackson wrote: > On Mon, 2007-03-12 at 18:59 -0400, William Cohen wrote: > > > # opreport -t 1 -l /usr/bin/Xorg > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > > Profiling through timer interrupt > > samples % image name symbol name > > 6514 68.1096 libfb.so fbFetchTransformed > > Wow. I think that's the first time I've ever seen this actually show up > on a profile. I didn't think anything used Render's transformations on > account of they're so painfully slow. > > > 613 6.4095 libfb.so fbFetchPixel_x8r8g8b8 > > Just as an aside, gcc generates some intensely dumb code: > > 00000d80 <fbFetchPixel_x8r8g8b8>: > d80: 55 push %ebp > d81: 8b 04 90 mov (%eax,%edx,4),%eax > d84: 89 e5 mov %esp,%ebp > d86: 5d pop %ebp > d87: 0d 00 00 00 ff or $0xff000000,%eax > d8c: c3 ret > d8d: 8d 76 00 lea 0x0(%esi),%esi > > Yay for frame pointers on leaf functions! I guess we can build X with > -momit-leaf-frame-pointer, it can't hurt but I have no idea if it'll > help measurably. It certainly makes the code prettier: > > 00000ce0 <fbFetchPixel_x8r8g8b8>: > ce0: 8b 04 90 mov (%eax,%edx,4),%eax > ce3: 0d 00 00 00 ff or $0xff000000,%eax > ce8: c3 ret > ce9: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi > > > 398 6.1099 : x1 = MOD (x1, > > pict->pDrawable->width); > > 383 5.8796 : x2 = MOD (x2, > > pict->pDrawable->width); > > 336 5.1581 : y1 = MOD (y1, > > pict->pDrawable->height); > > 355 5.4498 : y2 = MOD (y2, > > pict->pDrawable->height); > > It feels like we ought to be able to MMX this pattern. > > > : ft = FbGet8(tl,0) * idistx + > > FbGet8(tr,0) * distx; > > : fb = FbGet8(bl,0) * idistx + > > FbGet8(br,0) * distx; > > 536 8.2284 : r = (((ft * idisty + fb * disty) >> > > 16) & 0xff); > > : ft = FbGet8(tl,8) * idistx + > > FbGet8(tr,8) * distx; > > : fb = FbGet8(bl,8) * idistx + > > FbGet8(br,8) * distx; > > 482 7.3994 : r |= (((ft * idisty + fb * disty) > > >> 8) & 0xff00); > > : ft = FbGet8(tl,16) * idistx + > > FbGet8(tr,16) * distx; > > : fb = FbGet8(bl,16) * idistx + > > FbGet8(br,16) * distx; > > 514 7.8907 : r |= (((ft * idisty + fb * disty)) > > & 0xff0000); > > : ft = FbGet8(tl,24) * idistx + > > FbGet8(tr,24) * distx; > > : fb = FbGet8(bl,24) * idistx + > > FbGet8(br,24) * distx; > > : r |= (((ft * idisty + fb * disty) > > << 8) & 0xff000000); > > 512 7.8600 : buffer[i] = r; > > And maybe this one. > > But the more serious question is why we're hitting this path at all. I > can't think of anything in the described firefox use profile that would > require filters or transformations. The only place I can see the word > 'bilinear' mentioned at all in firefox is > > modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp: > nsIconChannel::InitWithGnome() > > but that seems unlikely. And more importantly it doesn't look like > we'll ever hit fbFetchTransformed without an actual transformation > matrix. Someone who knows firefox want to chime in here? > > - ajax > > _______________________________________________ > Devel mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel > > _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
