I ran Quantify on viewer last night (Solaris 2.6, totally debug build, gcc 2.7.2.3, GTK 1.2.0, etc) Doing a run like this: start up load example 0 go to example 4 and let it load exit nsImageGTK::Draw() is called some 250 or so times. 13-14% of execution time is spent within moz_gdk_draw_bgr_image() If you count the time spent in everything called by moz_gdk_draw_bgr_image(), then you are looking at around 84-85% of total execution time. about 85% of that time is spent within gdk_draw_bgr_image(), so it isn't entirely the fault of the bit twiddling that goes on there for some platforms (like mine). Some things to consider: Can we do the bit manipulations for the platforms that need it for RGB->BGR conversions in place in the image? Should we be dithering in GTK code? Is there any dithering happening in imglib? Why are we doing the RBG->RBG conversions on every draw? Why not cache this? Are we forcing the Xlib buffers to get flushed too often (and driving up network overhead)? Pavlov reported numbers a lot higher than I saw for that test run (about 399 calls to nsImageGTK::Draw(), also running viewer). I sent ramiro the quantify data that I had on this. Assigning to ramiro at pnunn's request.

Yes, dithering is handled in imglib. Ramiro, I'll be happy to work with you on the RGB/BGR ordering for all platforms once I get my carpool landed. email me. -pn

reassigning to me. i'm pretty sure I know whats going on here and am working to fix it. Pam, I will have some questions for you later.

pavlov: Thanks for jumping in. You might want to scan the history on bug#1879. If this is the same/&or related problem, we've got to look at a fix for all platforms. tor's fix only worked for a code path through gtk. later, pnunn

Just a quick note. I may have a good fix for the RGB/BGR problem, but I've got to test like crazy and will need to coordinate with FE's of all platforms. -pn

post a patch to mozilla.patches & mozilla.unix! -Chris

i just checked in a fix for this. elig: if you want to verify the fix, try demo 4 on the viewer on a build before and after march 26.

*** Bug 4221 has been marked as a duplicate of this bug. ***

Sure. Will check when we have a build that works. ;)

I was able to get a build on this this morning and verify that it was much much faster. Quantify numbers show that with the old code, doing the same 'run' as my initial report spent 81% of total execution time in nsImageGTK::Draw() and with the new code, that is a bit less than 6%. This is great.

If it's good enough for Bruce, it's good enough for me! Thanks, Bruce!

sorry for bugzilla spam. trying to get these off my radar

Re-flagging as Verified.