Firefox and Mesa

Recently, the Firefox team updated their support for software rendering so that they use the standard Mesa library that’s distributed with most Linux variants.

As far as I understand it, Mesa can be compiled to have all of its OpenGL functions start with “gl”, which is the default (and follows the OpenGL specification), or with “mgl”, which is useful for applications that are linking not just with Mesa but also with another 3D API (see here).

Historically, Firefox’s software rendering used Mesa in its “mgl” mode. Vladimir Vukicevic kindly made an mgl compile of osmesa32.dll available on his website for people to download and use when they needed to try software rendering. This was great for Windows users, but made life harder for those on Linux; most Linux distros have easily-available Mesa packages, but these are generally built with “gl” function names.

The new version of Firefox uses “gl” function names, which makes life a lot easier for Linux users. But it seems to leave Windows users in a bit of a bind.

Unfortunately, there are no official pre-compiled Windows Mesa binaries that I can find. I’d be happy to build and host them myself, but I was wondering — does anyone know of a better way of distributing them? Or, indeed, have I completely misunderstood the problem?

[UPDATE] In the comments, Benoit (who is coding this stuff in Minfield) says that he’s adding code so that it will support both “gl” and “mgl” function names, which will be a great result for everyone. You can track the progress of the work here.

[UPDATED UDPATE] The plan is now to only support “gl” function names, but to make a compiled OSMesa32.dll easily available for Windows users. This sounds like a good plan too :-)

You can leave a response, or trackback from your own site.

19 Responses to “Firefox and Mesa”

  1. guciek says:

    I did not test it, but I remember someone mentioning that the change in library loader will only affect Unix systems.

  2. Benoit says:

    Right, your explanation is correct! It’s true that we now only look for function names starting in “gl” so if your OSMesa library has “mgl” function names, then it can’t be used.

    I didn’t realize that it would be hard for Windows user to find a “gl”-prefixed build of OSMesa.

    The good news is that it’s really easy to detect this automatically, so I think I’ll do that.

    I’ll try to keep you posted but blog comments aren’t the most convenient discussion media! Maybe use mozilla’s bugzilla or mail me, when you have a concern about this?

  3. bfalese says:

    Is there a way to access a compiled Mesa lib distribution for Windows with “gl” function names?

  4. giles says:

    Hi Benoit,

    That’s great news! — And sorry — you’re right, I should have dropped you a line before posting :-(


  5. Alvaro says:

    While very excited about its possibilities and wanting it to be enabled in browsers ASAP, I have some concerns on WebGL due to its dependency on OpenGL 2.x hardware. Here go some recent thoughts. OK, you have MESA to make it work on other hardware, but in my tests that is terribly slow, even on fast CPUs. I don’t like the idea of a feature of the Web that relies on specific hardware support.

    In my netbook, even the simplest demos (i.e. HelloWorld at run at ~1.8 fps, and only at 5 fps in my Core2 Quad, via OSMESA. Examples with more complex rendering may take seconds per frame (e.g. GLGE).

    Such simple demos only do classic OpenGL rendering (i.e. gouraud+per vertex phong+diffuse texture like the fixed pipeline did) which could be done faster even in software or via OpenGL 1.x hardware, such as Atom netbooks. The problem is that being all based on programmable shaders, it’s very difficult to know if the rendering could be handled by old hardware: even a Gouraud rendering is represented as a shader which must be compiled and run.

    What I was wondering now is if it would be possible to do the following: have a smart analyzer of GL shaders which could identify operations supported by older fixed pipeline hardware and convert them to calls to the old API. That is, if we analyze a pixel and a vertex shader pair, we may see that all it does is compute Phong’s or Blinn’s lighting, use one texture in the diffuse part, etc. That could be converted to OpenGL 1.x and be run with acceleration even in old or simple hardware. If the shader makes more complex calculations, the conversion would lose fidelity but still run fast (unless the user wants more quality at the expense of speed). You see what I mean? Is is too crazy?

    Without something like this, WebGL would not be practical, at least until OpenGL 2 hardware is *everywhere*. In a practical scenario, suppose you have a client who wants a 3D application for his Web site, which is targeted at all kinds of home users, young, old, geeks and not geeks. I wouldn’t base development on a technology that will not work for a good part of their users.

  6. bfalese says:

    Thanks for such a hasty response. For the moment the solution seems to revert to an older build.

  7. Vlad says:

    Actually, using the mgl prefix makes things much harder on windows users — with the exception that there are (very old at this point!) precompiled dlls for mesa with the mangling. The reason for this is that the stock mesa build project files for win32 generate an osmesa dll that uses the ‘dll’ prefixes; I had to do a bunch of ugly hacking to generate mgl-prefixed names.

    I’m happy to rebuild the latest mesa version with gl-prefixed names for OSMesa though, if that would simplify matters.

  8. Benoit says:

    Vlad: then why don’t we just also check for dll prefixes, on windows? I mean, it’s so easy for us to do! By contrast, asking users to use only certain builds of OSMesa seems more tiresome, no?

  9. Benoit says:

    Update – Vlad tells me that the ‘dll’ above was a typo and was supposed to be ‘gl’ – hence, assuming gl prefixes for everybody is really the way to go. The mgl prefix thing was specific to his old OSMesa/windows build.

  10. giles says:

    @Vlad, Benoit — according to the OSMesa website, mgl prefixes are something you should be able to switch on using a command-line switch when building — maybe that’s a new thing, added after Vlad built his version.

    Either way, though, I agree 100% that making a pre-compiled Windows osmesa32.dll with “gl” prefixes available, and only supporting “gl” prefixes in Minefield, is a good solution to all of the confusion and problems.

    @Alvaro — that’s an interesting idea, but it would be hard to write code that could catch even a reasonable number of all of the varied ways that people could write Goraud shaders. From what I’ve heard, the lack of OpenGL 2.0-capable drivers is much more of a problem than a lack of hardware; at least when talking about Windows machines, almost all machines out there can handle programmable shaders, but only via DirectX. Google’s ANGLE project, which translates WebGL shaders and calls into OpenGL, should help out there.

  11. Alvaro says:

    Thanks for the reply. Would ANGLE benefit users of Intel GMA hardware? I’m thinking about Atom Netbooks which are supposed to be mainly for browsing the Web, and there are probable hunrends of thousands out there. ION would be safe, I guess. Sorry for being quite off-topic here :-)

  12. giles says:

    Do you mean Netbooks running Windows? If they support DirectX, then I guess it would help.

    OTOH Linux netbooks with no OpenGL drivers might be out of luck…

  13. Phoenix says:

    Hey everybody, I’m working on a project WebGL windows, I do what they said but it does not work, I downloaded minefield and I changed the settings from about: config but not webgl activated.
    I searched the forums and I discovered that I must download the librairy OSMesa but I think it is not available for windows xp but only for linux.
    please i really need your help because I do not know what to do in my project.

  14. giles says:

    Hi Phoenix — what kind of graphics card do you have? Have you updated to the latest drivers?

  15. Phoenix says:

    mobile intel(R) GMA X3100
    of which drivers you speak of?
    give me some indications please

  16. giles says:

    Phoenix — the drivers for the graphics card. However, if you’ve got an Intel graphics card on Windows, then unfortunately you’re not going to be able to get WebGL running right now without Mesa regardless of which driver you use, as their drivers don’t tend to support OpenGL 2.0.

    As you’ve already noticed, current versions of Minefield only support Mesa under Linux. However, older versions did work with a hacked-up version of Mesa provided by Vladimir Vukicevic; for now, you might want to try running this old version with this version of Mesa: See here for more information on configuring it all:

    In the longer term, things should get better:

    1. At some point, the Google ANGLE project will be integrated into Chrome and/or Minefield for Windows. This will mean that WebGL will be able to run using DirectX instead of OpenGL, so it is likely to work with your graphics card. However, I don’t know when this will be available.

    2. Perhaps in the shorter term, someone will make an appropriate version of Mesa available for Windows users. I tried building this myself, but unfortunately it’s not as simple as I was hoping. If and when I hear of an appropriate Mesa version becoming available, I will blog about it.

  17. Phoenix says:

    GILES Thank you for your help, I downloaded what you gave me and it worked
    you’re awesome sir, thank you very much
    have a nice day

  18. giles says:

    Excellent, happy to hear it worked!

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter