362360 - SVGs don't display with Matrox driver on OS/2

Status: VERIFIED FIXED

(Core Graveyard :: GFX: OS/2, defect)

Description

[Peter Weilbacher]

It has been reported to me twice now that objects that are drawn through the cairo library (SVGs in webpages and tab previews with SeaMonkey 1.1b) don't appear on the screen when the Matrox display driver is used on OS/2.

Ingo Steiner was so nice to switch his machine from Matrox to Scitech SNAP temporarily for a test and this confirmed that the only difference is the display driver. It is currently unknown to me what differences exist between Matrox and SNAP that would explain this and but especially in the light of Thebes, I want to check what happens and if something could be changed in the Mozilla code to work around that problem.

Comment 1

[Andy Willis (abwillis)]

I believe the Cairo code may require SNAP.  At the very least it requires sddhelp.sys but I think it relies on some SNAP code.

Comment 2

[Peter Weilbacher]

I asked Doodle about it and with his help I was able to confirm that if the undocumented Gpi APIs GpiQueryYInversion() and GpiEnableYInversion() (in the _cairo_os2_surface_blit_pixels() function in cairo-os2-surface.c) are not called, I get the same failure on a SNAP system as reported by the Matrox users. So the preliminary conclusion was that these APIs don't work on non-SNAP drivers.

It should be possible to work around the problem by painting lines one by one just that my current code for that doesn't work...

So it seems to be more of a cairo problem and less of a Mozilla one, but I suggest to keep this bug open until the matter in cairo is resolved. We should then also check a fix into branch.

Comment 3

[Andy Willis (abwillis)]

I don't have any video cards that have drivers other than SNAP so I can't test this but it is possible that SNAP is not required to be the driver.  Try adding sddhelp.sys (DEVICE=D:\OS2\SDDHELP.SYS) and that may be all that is required.

Comment 4

[Peter Weilbacher]

After fiddling around with this on and off over the last weeks, I was finally pointed to the fact that the Matrox driver cannot display 32bit bitmaps which is exactly what cairo was trying to do. I pushed a workaround (that gets Matrox going albeit slowly) into cairo upstream last night, see
http://gitweb.freedesktop.org/?p=cairo.git;a=commitdiff;h=e6369f9478e84e32ca19d5f204dbe3eee828c429
so this will get into trunk "automatically" at some point. I will shortly create a 1.8 branch patch from this.

Andy: no, I'm told that adding SDDHELP.SYS to a Matrox installation does not help.

Comment 5

[Peter Weilbacher]

Attachment: Workaround for buggy display drivers

Corresponding to commit e6369f9478e84e32ca19d5f204dbe3eee828c429 to cairo trunk. Doesn't affect operation on working display drivers on OS/2, and only changes an OS/2 file, so is NPOTB.

Andy, if you build branch one of these days, could you confirm that it doesn't break the build? (Note that it will break trunk because the variables are named differently.)

Comment 6

[Peter Weilbacher]

Comment on attachment 250486 [details] [diff] [review]
Workaround for buggy display drivers

This code is in an OS/2-only file and is not built in the Firefox branch releases which have SVG disabled. So NPOTB applies. It has been on trunk and upstream in the cairo library for months now without ill effects, so I will check it in without extra review one of these days. Unless somebody objects...

Comment 7

[Peter Weilbacher]

Checked into branch.

Comment 8

[Peter Weilbacher]

As only my private builds do contain support for SVG and it was verified as fixed by the concerned user with one of those, I mark this as verified, too.