Quote of the week [LWN.net]

Too bad that this means a huge blow for Free Software, as we're only accelerating Windows and therefore showing people how much better everything runs on that proprietary system compared to the ugly sucky Linux stuff. I still dream of a world where we advocate open software, but either it's far in the future or it has passed already.

-- SeaMonkey developer Robert Kaiser

to post comments

Running the Windows version

Posted Jun 17, 2010 13:42 UTC (Thu) by epa (subscriber, #39769) [Link] (3 responses)

Wine has some support for DirectX and Direct3D; good enough to play many popular games. Perhaps running the Win32 build of Firefox or SeaMonkey under Wine might give better results for less effort than maintaining a separate GTK/X11 port.

Running the Windows version

Posted Jun 17, 2010 14:12 UTC (Thu) by nye (guest, #51576) [Link] (2 responses)

I guess you were joking, but the win32 build of Firefox running under Wine does have a reputation for being faster, less bloated, and at least no less stable compared to Linux native builds :-(.

(I did use it fairly extensively for a while and the only reason I stopped was because I was constantly slightly frustrated by a number of small integration problems - little things like not being able to middle-click to paste the selection for example)

On the other hand Wine's d3d is excruciatingly slow compared to native performance, and I'm not sure it supports Direct2D at all, so that's unlikely to be a win.

Running the Windows version

Posted Jun 18, 2010 5:50 UTC (Fri) by TRS-80 (guest, #1804) [Link] (1 responses)

Gecko actually supports a lot of the n*x UI behaviours with prefs, so you can set them to true on Windows. middlemouse.click would help you, I quite like middlemouse.scrollbarPosition. You're right that Direct2D is too new to be supported, but their DX9 support (which Firefox uses for 2K/XP) is maturing, and with video cards so powerful these days losing half your performance isn't that bad.

Interestingly, Wine's D3D to OpenGL translator on Mac (in Crossover Games) outperforms the native version of Valve's Source engine, which apparently has its own translator rather than being rewritten in OpenGL.

Running the Windows version

Posted Jun 22, 2010 12:13 UTC (Tue) by nye (guest, #51576) [Link]

>Gecko actually supports a lot of the n*x UI behaviours with prefs, so you can set them to true on Windows. middlemouse.click would help you, I quite like middlemouse.scrollbarPosition

I had no idea those were supported on the Windows builds. Thanks for pointing that out!

Quote of the week

Posted Jun 18, 2010 21:39 UTC (Fri) by KaiRo (subscriber, #1987) [Link] (2 responses)

This quote from me is probably a bit overstated - but still, the real solution to the problem, from what I've learned since I wrote that, is to make the 3D graphics stack on Linux more usable and reliable, esp. getting 3D drivers out there that allow client applications like Firefox or SeaMonkey to consistently and reliably work with the same set of APIs on all the drivers.

Given the current state of the Linux graphics stack, esp. 3D drivers, it's hard for e.g. Mozilla people to develop good acceleration for it, and apparently that's why they focus their work more on the Windows side right now. Which also means, that you can best help by improving the graphics stacks and 3D drivers.

If we manage that, my dream is in an at least reachable future - even if it's probably not in Firefox 4 and SeaMonkey 2.1 yet, which are still to be released this year.

Quote of the week

Posted Jun 25, 2010 15:36 UTC (Fri) by josephrjustice (guest, #26250) [Link] (1 responses)

This quote from me is probably a bit overstated - but still, the real solution to the problem, from what I've learned since I wrote that, is to make the 3D graphics stack on Linux more usable and reliable, esp. getting 3D drivers out there that allow client applications like Firefox or SeaMonkey to consistently and reliably work with the same set of APIs on all the drivers.

Given the current state of the Linux graphics stack, esp. 3D drivers, it's hard for e.g. Mozilla people to develop good acceleration for it, and apparently that's why they focus their work more on the Windows side right now. Which also means, that you can best help by improving the graphics stacks and 3D drivers.

I can't argue with that, of course. But, I wonder -- if, on the Win32/64 platform, the native 3D graphics stack (e.g. DirectX#, et al) remains at least non-trivially if not substantially better in terms of performance on that platform than the implementation of a Unix/Linux-available 3D graphics stack (presumably OpenGL, etc) on the Win32/64 platform, then why would the Windows build of FFx, et al switch to using the Unix/Linux-available 3D graphics stack for the Windows build instead of the Windows native graphics stack? And, if the Windows build of Ffx, et al does *not* do this, then how can it be said that the client application is working with the same set of APIs? I mean, that's what I'm parsing your claim here (plus the message pointed to by the original article) to kind of imply being ultimately desirable to achieve.

Now, if all you meant is that you wanted to use the same set of APIs on all related / similar implementations of a given platform, which for Unix/Linux would probably mean all major / dominant distributions of Linux (e.g. Fedora and RHEL, Debian, Ubuntu+, SUSE, maybe Gentoo and Slackware, etc), plus FreeBSD and its derivatives, Net and OpenBSD, etc, plus maybe some of the other open source Unix-alikes using X, OpenGL, etc, then I could see that.

But, I have to think that the version of X, OpenGL, etc available on Win32/64 by default would have to get pretty close to MS's stack in terms of performance (say at least within 10-20%) before the Windows build would give up using the MS stack, unless the cost of code development / maintenance using the MS stack is truly horrid. (And since the MS build of FFx, et al is presumably still the overwhelmingly dominant version of FFx in actual use, that cost would need to be *truly* horrid before it wasn't worth using the native MS APIs if those APIs gave non-trivial performance benefits. Of course, the MS build of FFx being overwhelmingly dominant in terms of usage also helps to explain why the MS build would get more development resources and focus in general, et al.)

Or, who knows... Maybe I'm all wrong! In any event. Hope this was of some use, interest. Thanks for your time. Be well.

Joseph

Quote of the week

Posted Jun 25, 2010 15:59 UTC (Fri) by KaiRo (subscriber, #1987) [Link]

I meant "the same set of APIs" in terms of Linux drivers, as I'm told that there's not a single set of APIs that are stable enough to heavily use across the available Linux drivers.
Of course, Windows hardware acceleration uses D3D/D2D/DirectX or whatever the native interfaces are there - and those are apparently way more consistent and usable in themselves than what we have on Linux right now.