build: 99010812 on RedHat 5.2 and MacOS 8.5 Mac and linux both have a problem with rendering demo #10. MAC: the animated gear background appears fine. so does the <HR>. but the three transluscent gifs and the enlarged gear gif are painted as white squares (with correct dimensions). LINUX: the background paints but does not animate. the <HR> appears fine. the four animated gifs in the foreground do not even appear as white boxes. and Seamonkey keeps the cpu spinning like a top, repainting very slowly and pushing the gears foreward at about 1 frame every 7 seconds.

need blender implementation for each platform to fix this.

the animation problems should be fixed now under linux. isn't blender implimented in the image library and not natively?

ok, i'm using build 99020213 (Feb 2) on linux. ( mac windows, same day, work fine) On linux (on my PII 266): The animation is marginally faster now, i admit, but it's nowhere close to the 32bit windows build. also, it is still slower than the same animated gif in "demo #1" so here's what's left for parity: 1. opacity (alphablending) of images on linux and mac 2. background image loading time on linux are these issues handled by the os or by seamonkey/gecko?

Putting [Perf] in the Status Whiteboard since we have some performance problems here also.

Inserting Milestone info.

Setting all current Open/Normal to M4.

setting Eli as QA assigned to

blender is XP and works under unix.

blending is now xp. any problems that remain should be re-written up as either mac specific (since that is the only platform for which nsIDrawingSurface::Lock() has questionable functionality), and assigned to patrick beard or for all platforms.

Using 4.9.99 AM build, Mac and Linux only display the gear background and the HR; none of the additional images display at all. Michael, per your 4.7.99, would you like me to break this into a separate bug...? thanks!

elig: yes, please break this up into 2 bugs. one for the mac and one for linux. assign the linux one to me and the mac stuff as michael describes above. thanks.

to I'll move this one to beard. Eli, can you open one and assign to ramiro for linux? moving to m5

to I'll move this one to beard. Eli, can you open one and assign to ramiro for linux? moving to m5.

Sure. I'll split out the Unix bug. I'd rather close this bug out and write up new ones, since the behavior has changed quite a bit over the past three months, and this one is becoming increasing hard to follow as a result. (If anyone objects to this, please let me know ASAP, or it may be too late. ;) Thanks.

[Unix issue broken into 5053, assigned to ramiro.]

[Also, Mr. Beard, the current Mac behavior on the 4.9.99 M4 build is equivalent to the behavior in 5053 --- except that the Mac: a. doesn't have the opaque eyeballs b. doesn't have the flashing chrome. c. totally horks in a multiple nasty ways if you resize it a few times. (doesn't fill expanded space with background, window contents go white, sometimes crashes, etc. Can write up as separate bug report.)

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

[I'm going to break this out into two separate bugs, per bug #1307.]

Okay. This bug was branching out into too many issues, and most of the issues Phillip raised has been fixed. I've now broken the Mac issue into bug #5081, with a crashing use case scenario. (As noted before, the Linux stuff is now in bug #5053.) So, I'm marking this bug as Verified/Fixed. Anyone who sees something that I'm not seeing, please re-open this with your comments. (Phillip, are there still performance problems? I'm not seeing them, but I don't have a visceral gestalt for the feel of the Linux platform, and the performance always seems slow to me no matter what app I'm using. ;)

for the record, the performance is many orders of magnitude better on linux.