338786 - Canvas reflections not drawn on 1.8 branch & trunk on 10.3.x

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The image "reflections" on the URL in question do not appear at all on the 1.8(.1) branch (latest Camino 1.8branch nightlies and BEalpha2); the reflections appear fine, however, on the 1.8.0 branch and on the trunk.  10.3.9 here.

This is probaly a regression from the branch canvas update, bug 333613; regression range based on Camino 1.8branch nightlies: http://tinyurl.com/ju6zt

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Works for me using the 2006-05-21 Windows 1.8 branch nightly.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Using an Intel Mac (OSX 10.4) and Bon Echo Alphas 2 or 3, none of the following URIs show their canvas-y bits to me:

http://cow.neondragon.net/stuff/reflection/
http://rig.vlad1.com/~vladimir/canvas/cdemo1.html
https://update-staging.mozilla.org/~clouser/cakesurvey/results/?start_date=&end_date=&product=Mozilla+Firefox+1.5.0.2&submit=Go

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

So this works for me, using my own build; it doesn't work if I use the tinderbox builds.  My own builds are straight intel mac builds, with the latest SDK -- I wonder if that has something to do with it?

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

PPC Tinderboxes use:

--target=powerpc-apple-darwin8.5.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk 
--enable-application=browser 
--enable-update-channel=beta 
'--enable-optimize=-O2 -g' 
--disable-debug 
--disable-tests 
--enable-update-packaging 
--enable-static 
--disable-shared 
--enable-prebinding 
--enable-svg 
--enable-canvas

MacTel Tinderboxes use:
--target=i386-apple-darwin8.5.0 
--with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk 
--enable-application=browser 
--enable-update-channel=beta 
'--enable-optimize=-O2 -g' 
--disable-debug 
--disable-tests 
--enable-update-packaging 
--enable-static 
--disable-shared 
--enable-svg 
--enable-canvas

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I just finished a full universal build, with identical mozconfig as what's used for the release builds, and my builds do canvas fine.  The build's available at http://people.mozilla.com/~vladimir/misc/be.tar.gz .  The only difference that I see is that I have --target=(powerpc|i386)-apple-darwin8.6.1, where the release builds have 8.5.0.  I'm running 10.4.6 on an Intel iMac; what do we do the release builds on?  Could this be causing the problem?

Cc'ing mark, bsmedberg, and build folks..

Comment 6

[Mark Mentovai]

8.6.1 is the kernel version reported by 10.4.6/x86.  That number isn't used for anything at all, it's just taken from the `uname -r` of the build host.  Release builds are produced on 10.4.5/ppc, which reports 8.5.0.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Shouldn't the trunk mozconfigs/--target options be the same as the branch, anyway?  The reflections work fine on the trunk (at least for Camino; I don't have a Minefield handy).

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #6)
> 8.6.1 is the kernel version reported by 10.4.6/x86.  That number isn't used for
> anything at all, it's just taken from the `uname -r` of the build host. 
> Release builds are produced on 10.4.5/ppc, which reports 8.5.0.

Yeah, that's what I figured.  I'm now completely baffled, since I think build host is now the only variant -- I'll do a universal build on my G5 here at home and see if I can reproduce this.  (To be clear, it's not just the reflections -- any canvas stuff doesn't work/show up.)  Note that the release build had the same non-working behaviour whether I ran the x86 code natively or if I forced it to run the PPC code with Rosetta (I'm assuming that's what the "Run with Rosetta" or whatever option in Get Info does).  My build worked correctly both ways.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

A universal build done on my Intel iMac, xcode 2.2, SDKs 10.2.8 and 10.4u, has a working canvas.
A universal build done on my G5, xcode 2.2, SDKs 10.2.8 and 10.4u, does not have a working canvas.

I have no idea what's going on; I'll debug it on the G5 and try to see what the problem is.

Comment 10

[Mark Mentovai]

In an x86-only 1.8-branch build on my MacBook Pro, I don't see the reflections.  10.4.6, Xcode 2.3, configured with --enable-application=browser --enable-canvas --disable-debug --enable-optimize=-g --disable-prebinding --enable-shared --disable-static --disable-strip --enable-svg --disable-tests --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk

In identically-configured 1.8.0 and trunk builds, I do see the reflections.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hm, I should update my Xcode version (I'm using 2.2.1); will try that.

Comment 12

[Dietrich Ayala (:dietrich)]

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

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix canvas on the mac

This fixes canvas on the Mac; we just use the already-existing functionality to get a CGContext out of gfx instead of trying to do it ourselves (in a buggy way).

Comment 14

[Mark Mentovai]

Comment on attachment 225518 [details] [diff] [review]
fix canvas on the mac

+ifeq ($(MOZ_GFX_TOOLKIT),mac)

This caused Cocoa builds to fail.  Since this is the 1.8 branch, that only means Camino.  I've changed this line to:

+ifneq (,$(filter mac cocoa,$(MOZ_GFX_TOOLKIT)))

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #14)
> (From update of attachment 225518 [details] [diff] [review] [edit])
> +ifeq ($(MOZ_GFX_TOOLKIT),mac)
> 
> This caused Cocoa builds to fail.  Since this is the 1.8 branch, that only
> means Camino.  I've changed this line to:
> 
> +ifneq (,$(filter mac cocoa,$(MOZ_GFX_TOOLKIT)))

Whoops, sorry about that; I'll fix that before I check in on trunk.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #15)
> (In reply to comment #14)
> > (From update of attachment 225518 [details] [diff] [review] [edit] [edit])
> > +ifeq ($(MOZ_GFX_TOOLKIT),mac)
> > 
> > This caused Cocoa builds to fail.  Since this is the 1.8 branch, that only
> > means Camino.  I've changed this line to:
> > 
> > +ifneq (,$(filter mac cocoa,$(MOZ_GFX_TOOLKIT)))
> 
> Whoops, sorry about that; I'll fix that before I check in on trunk.

That change seems not to have made it in to the trunk checkin; maya and boxset are burning with same canvas error (pawn seems to be burning from something else).

Comment 17

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This is because I'm incompetent and made the fix on a different trunk checkout than where I checked in from.  Sigh, sorry =/  Looks like someone beat me to the fix.

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Heh, now it's my turn to apologize for not verifying the branch checkin sooner :(

On 10.3.9, today's 2006-06-15 1.8 branch nightlies of Camino and Firefox both still fail to display the reflections at the site above.  

The reflections work fine on 10.4.x PPC in the very same Camino nightly, so something's still not right on 10.3.x only (or 10.3 and 10.2, but no 10.2 around to check, and Camino doesn't support 10.2 on 1.8.1 anyway.)

Reopening and clarifying the summary.

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(I'm aware this is getting dangerously close to evil bug-moprhing, but since it was *never* fixed on 10.3.9...)

mento had me check, and the first successful Camino Trunk tinderbuild after this landed on the trunk is broken on 10.3.9 (and it was working prior to that).  mento was going to do some poking around....

Comment 20

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's identical code on branch & trunk for this, so I'm not surprised it's not working on the other if it's not working on one.  It might have something to do with the pixel formats, but.. I only have 10.4 machines handy (both PPC and x86, but 10.4 only), but I'll find a 10.3 machine tomorrow -- I bet we have some in the QA area.

Comment 21

[Jean-Yves Perrier [:teoli]]

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

Comment 22

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ok, it's the actual CGImage handling that's broken -- everything else is getting set up right, since I can draw with CG just fine into the region where the image would be painted if I do a CGContextFillRect.  Investingating further now...

Comment 23

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix for 10.3

I should've known that Apple would break backwards compat.  CG versions earlier than 10.4 can't deal with anything in the bits that indiciate byte order; they have to be set to 0.  Why Apple just didn't define kCGBitmapByteOrder32Big to be 0 and have Little just set that field to 1, I have no idea.  This fixes things on 10.3 and continues to work on 10.4.

Comment 24

[Mike Schroepfer]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1a3) Gecko/20060611 BonEcho/2.0a3

Please note I'm seeing this bug on 10.4.6 Intel Mac.

Comment 25

[Blake Kaplan (:mrbkap) (inactive)]

I just checked attachment 226356 [details] [diff] [review] into the 1.8 branch for vlad.

Comment 26

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This seems fixed for me on the 1.8 branch; can someone confirm that?  I still need to update it for the trunk, will do that today.

Comment 27

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yes, this is fixed on the branch; sorry.

Comment 28

[Stefan [:stefanh]]

vlad, was there any problem updating the patch for trunk?

Comment 29

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Youch, no idea why I haven't checked this in to trunk yet.

Comment 30

[Biju]

Still a problem in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061016 Minefield/3.0a1
Bug#: 351113