Closed Bug 362360 Opened 14 years ago Closed 13 years ago

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

Categories

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

1.8 Branch
x86
OS/2
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

Details

(Keywords: verified1.8.1.5)

Attachments

(1 file)

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.
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.
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.
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.
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.
Severity: normal → minor
Status: NEW → ASSIGNED
Version: Trunk → 1.8 Branch
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.)
Attachment #250486 - Flags: review?(abwillis1)
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...
Attachment #250486 - Flags: review?(abwillis1)
Checked into branch.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: fixed1.8.1.5
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.