4229 - Slowness in image rendering on unix.

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Bruce Mitchener]

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.

Comment 1

[pnunn]

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

Comment 2

[stuartp]

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.

Comment 3

[pnunn]

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

Comment 4

[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

Comment 5

[Chris McAfee]

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

Comment 6

[ramiro]

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.

Comment 7

[ramiro]

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

Comment 8

[Eli Goldberg]

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

Comment 9

[Bruce Mitchener]

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.

Comment 10

[Eli Goldberg]

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

Comment 11

[Stuart Parmenter]

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

Comment 12

[Eli Goldberg]

Re-flagging as Verified.