342644 - Upgrade SVG/Canvas on OS/2

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Peter Weilbacher]

With this bug I want to address several issues:

- Canvas needs to be updated for OS/2 on trunk, it seems that
  in the current state canvases crash the browser since it was
  overhauled since the SVG/Cairo OS/2 activation
- I think it makes sense to overhaul the required library/setup a
  bit, to make use of the library/files that I compiled for my
  PmW-* packages.
- SVG/Canvas needs to be brought to the same state on 1.8 branch
- For self-compilers there should be instructions on the gccsetup
  page how to build with SVG support

Draft patches coming soon.

Comment 1

[Peter Weilbacher]

Attachment: Patch for trunk [checked in]

- buildconfig change:
  expects to have the package
     http://weilbacher.org/Mozilla/mozfntcfgft_29Apr2006.zip
  to be installed. Then only a single directory variable is
  required in setmozenv.cmd that contrary to the contained ReadMe
  (I will update the package before linking on gccsetup page)
  should be called MZFTCFGFT2, i.e.:
     'set MZFTCFGFT=%ROOT%\mzftcfgft335'
     'set MZFTCFGFT2='backtoforward(value('MZFTCFGFT',,'OS2ENVIRONMENT'));
  Then the distributed MozApp depends on mzfntcfg.dll but I see no
  way around that anyway.

- fixes Canvas crash

- fixes upside-down svg:image display

Comment 2

[Peter Weilbacher]

Attachment: SVG/Canvas for 1.8 branch

This contains the patch from bug 305028, small parts of the BeOS patch from bug 323551 (buildconfig), and the extra changes from the trunk patch (attachment 226946 [details] [diff] [review]).

Comment 3

[Peter Weilbacher]

To go with these patches, the build instructions page
   http://www.mozilla.org/ports/os2/gccsetup.html
should have a link to the extra package, probably below the Perl link

   * Support package for Cairo-enabled builds [mozfntcfgft]
     Unzip mzfntcfgft*.zip in the root directory. It will create a
     directory called mzfntcfgft. Go to this directory and run make.

I have to update the package accordingly, and perhaps upload to Netlabs or Hobbes for a more stable link. I could also include precompiled binaries for GCC 3.3.5. What do you all think?

(Hmm, the name sucks but if I write it in full it gets really long...)

Comment 4

[Peter Weilbacher]

biesi, this might be interesting for you as well, in case you want to get SVG for BeOS on 1.8 branch.

Comment 5

[Peter Weilbacher]

Vlad, do you plan any more syncs with cairo on the 1.8 branch? OS/2 probably doesn't have a chance to get into cairo 1.0.x any more, so would you be willing to check the required OS/2 cairo additions into Mozilla branch directly?

Comment 6

[Peter Weilbacher]

Attachment: OS/2 cairo files for 1.8 branch

This would be the patch to do that.

Comment 7

[Andy Willis (abwillis)]

I think we would be better off stripping the cairo_call entirely.  It is really only useful if used in conjunction with the rest of the system.  

Comment 8

[Peter Weilbacher]

It doesn't really matter, for the way it is defined we know that it works. Changing it just makes more work. Or do you see a specific drawback of using _System with GCC?

Comment 9

[Andy Willis (abwillis)]

I don't know of any reason it should be a problem to use _System.  I had removed it because it is only useful for a standalone cairo.dll which we aren't building here and it was causing cvs conflicts when it was defined for all of Cairo.  I don't guess it really matters.

Comment 10

[Benjamin Smedberg]

Comment on attachment 226946 [details] [diff] [review]
Patch for trunk [checked in]

I am not a suitable reviewer for this change.

Comment 11

[Andy Willis (abwillis)]

Attachment: cairo 1.2 files with Mozilla updates -- Trunk

Cairo on trunk is at 1.19 or 1.2 (essentially the same for the OS/2 files).

Comment 12

[Andy Willis (abwillis)]

Mozilla builds expat internally.  Would it be beneficial to look into linking against it?

Comment 13

[Peter Weilbacher]

(In reply to comment #12)
> Mozilla builds expat internally.  Would it be beneficial to look into linking
> against it?

I don't think that's possible. fontconfig depends on expat that's why I ship the expat functions inside the mzfntcfg.dll. I don't know of any why in which I could build that DLL so that it again links to the to-be-built gkparser.dll (or firefox.exe). It would only save a few kB anyway...

Comment 14

[Andy Willis (abwillis)]

Attachment: Updated for recent Trunk changes

Recent Cairo update requires some changes to cairo-os2-surface.c.
Peter, does http://www.croczilla.com/svg/samples/svgtetris/svgtetris.svg crash your builds?  Mine has crashed there for some time, --enable-system-cairo builds work fine but cairo built in Mozilla crashes without a popuplog.os2 entry.

Comment 15

[Peter Weilbacher]

This kind of change is exactly the reason why we need the files upstream in cairo's repository. Otherwise you can upload these ZIPs here endlessly. Unfortunately, Doodle doesn't reply at all any more on this topic and the email to Dave bounced back to me.

What do you say, should I just take matters into my own hands and send the ones from your ZIP to the cairo-list?

And yes, last time I build trunk (20060526) with the files from the patches here it worked fine, no crashes, all colors correct, everything the right way around...

Comment 16

[Andy Willis (abwillis)]

I was able to speak to Carl over IRC the other day and got him to reply to Doodle's emails.  I haven't seen either one online since then so I don't know where things stand.  The problem with sending these particular files is that they have the Mozilla updates already in them, the ones on Netlabs are the ones that need to be put into the Cairo distribution.  

Comment 17

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

Comment on attachment 226949 [details] [diff] [review]
SVG/Canvas for 1.8 branch

r=me on the CanvasRenderingContext changes and the cairo-win32-surface change; the remainder are OS2-only build system and SVG changes.  Maybe tor for the SVG changes?  They look fine to me in general, since they're purely OS2-only.

Comment 18

[Peter Weilbacher]

vlad, thanks for looking at the patch.
Any hints on the question about future syncs of cairo on the 1.8 branch?

Comment 19

[Peter Weilbacher]

Comment on attachment 226949 [details] [diff] [review]
SVG/Canvas for 1.8 branch

tor, vlad suggested that you should take another look regarding the SVG changes.

mkaply, are you happy with the OS/2 part and the build changes?

Comment 20

[Peter Weilbacher]

Comment on attachment 226946 [details] [diff] [review]
Patch for trunk [checked in]

tor, I guess vlad left this for you, too.

Comment 21

[Mike Kaply [:mkaply]]

Comment on attachment 226946 [details] [diff] [review]
Patch for trunk [checked in]

sr=mkaply for OS/2 changes - I'm wondering why that nsSVGImageFrame.cpp #include wasn't already in?

Comment 22

[Mike Kaply [:mkaply]]

Comment on attachment 226949 [details] [diff] [review]
SVG/Canvas for 1.8 branch

Where is MOZ_ENABLE_CAIRO_FT used? I only see it being set. same with CAIRO_FT_FLAGS

Comment 23

[Peter Weilbacher]

Right, thanks for catching that. I believe I forgot to diff gfx/cairo/cairo/src/Makefile.in...

Comment 24

[tor]

Comment on attachment 226946 [details] [diff] [review]
Patch for trunk [checked in]

nsIImage.h was probably removed accidentally when I was pruning the includes in the svg frame code.

Comment 25

[Peter Weilbacher]

Attachment: SVG/Canvas for 1.8 branch (version 2) [checked into branch]

OK, this patch now includes the cvs diff of gfx/cairo/cairo/src/Makefile.in.

Carrying over reviews. Will ask for approval once I managed to check in the corresponding trunk patch.

Comment 26

[Peter Weilbacher]

Comment on attachment 226946 [details] [diff] [review]
Patch for trunk [checked in]

OK, checked this into trunk. I hope that on Win and Mac everything stays the right way up...

Comment 27

[Peter Weilbacher]

Attachment: Patch for gccsetup.html webpage

This is the update for the webpage http://www.mozilla.org/ports/os2/gccsetup.html that is needed to make the OS/2 cairo stuff work. I uploaded the new support package to my personal webspace
   http://weilbacher.org/Mozilla/mozfntcfgft_24Jul2006.zip
for now let me know if this should go somewhere else. The cairo files are now on the way into the cairo-git repository but to be sure I included the versions that I confirmed are working on trunk and both branches, so this also obsoletes Andy's ZIP file. (Andy, I now decided to completely remove cairo_call after all as you suggested in comment 7.)

Comment 28

[Peter Weilbacher]

Attachment: Required change to setmozenv.cmd

The required change to the build environment file.

mkaply: I would need you (or Felix "mrmazda") to update this file and the webpage in the web-CVS repository.

Comment 29

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

(In reply to comment #18)
> vlad, thanks for looking at the patch.
> Any hints on the question about future syncs of cairo on the 1.8 branch?

Probably never -- we didn't take a newer cairo on the 1.8 branch and I don't think that we will due to (afaik) various unresolved issues with SVG.

Comment 30

[Peter Weilbacher]

Comment on attachment 230458 [details] [diff] [review]
SVG/Canvas for 1.8 branch (version 2) [checked into branch]

Basically OS/2 only code changes with small buildconfig changes that have been on trunk since Jan 21 (bug 323551).

Comment 31

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

Comment on attachment 230458 [details] [diff] [review]
SVG/Canvas for 1.8 branch (version 2) [checked into branch]

a=drivers. Please land on the MOZILLA_1_8_BRANCH.

Please watch carefully in case the new buildconfig stuff breaks us, and be ready to back it out. We get nervous about big ol' buildconfig changes.

Comment 32

[Peter Weilbacher]

I mark this fixed1.8.1 now but will leave the bug itself open until the doc changes are done.

Comment 33

[Peter Weilbacher]

Attachment: Updated OS/2 cairo files for cairo 1.0.x/Mozilla 1.8 branch [checked into branch]

(In reply to comment #29)
> (In reply to comment #18)
> > vlad, thanks for looking at the patch.
> > Any hints on the question about future syncs of cairo on the 1.8 branch?
> 
> Probably never -- we didn't take a newer cairo on the 1.8 branch and I don't
> think that we will due to (afaik) various unresolved issues with SVG.

OK, then I would like your opinion on this patch that adds the OS/2 files to the Mozilla repository for 1.8.1. I also added a note into the README in case you decide to sync after all.

Comment 34

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

Comment on attachment 230636 [details] [diff] [review]
Updated OS/2 cairo files for cairo 1.0.x/Mozilla 1.8 branch [checked into branch]

Sure, that looks fine to me.

Comment 35

[Peter Weilbacher]

Comment on attachment 230636 [details] [diff] [review]
Updated OS/2 cairo files for cairo 1.0.x/Mozilla 1.8 branch [checked into branch]

Again, OS/2 only.

Comment 36

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

Comment on attachment 230636 [details] [diff] [review]
Updated OS/2 cairo files for cairo 1.0.x/Mozilla 1.8 branch [checked into branch]

a=drivers. Please land this on the MOZILLA_1_8_BRANCH.

Comment 37

[Andy Willis (abwillis)]

Regarding comment #14 I figured out that the problem was my freetyp2.  I had built it in one of the early 3.3.5 releases (b4 -- subsequent attempts to build freetyp2 with gcc have failed and I had never tracked down why).  Changing from its use to the mzftcfg cleared it up.

Comment 38

[Peter Weilbacher]

Comment on attachment 230636 [details] [diff] [review]
Updated OS/2 cairo files for cairo 1.0.x/Mozilla 1.8 branch [checked into branch]

checked this in

Comment 39

[Peter Weilbacher]

I am going to mark this fixed now. I decided that I will make the doc updates when I manage to move the gccsetup page to devmo.

Thanks to everybody for help and comments!