Using directx and/or opengl would make rendering faster on all the oses. We
could make it option-based so that if someone doesn't have the ability to run
directx or opengl they could use plain GDI (or linux equiv) rendering.
This is obviously something that is for the way future.
I fail to see how rendering using directX or openGL will be that much faster for
2-d rendering (which is what we are doing).
Make it so.
There's no need to use DirectX. OpenGL runs fine on Windows, AND it's cross
Things that would work better in OpenGL:
scaling (bilinear filtering!)
any kind of image drawing, actually (store images in texture memory)
Well, that list pretty much sums up everything that's slow about our current
drawing code :-).
In theory, video cards are faster at 2D rendering using OpenGL/DirectX because
that has been the "push", the "in thing", the "fad", the "what all perf
comparison charts use to say who's hot". So the video card manufacturers have
been pouring many manhours into developing the fastest 3D out there, usually at
the expense of speeding up their old 2D routines.
All the cool routines are in 3D mode, even the 2D ones ;)
Also GDI (win32) is made for basic rendering of widgets and such, not rich
multimedia rendering as is now required by browsers. It says that if you do
any kind of sophisticated multimedia, you should use DirectX (or opengl).
Mozilla isn't a text-mode application. ;-)
I love OpenGL. However:
Things that would likely work worse in OpenGL:
. Text rendering (uh-oh)
. Drawing to an offscreen image (double-buffering -- when
you swap buffers in OpenGL the new backbuffer's contents
become undefined. Single-buffering would give flicker.
Hardware-rendering to an offscreen pixmap is nonstandard.)
. Screen-screen copies (scrolling!)
I think that an OpenGL front-end would be groovy and IS doable,
but there are some real potential design/performance/interoperability
pitfalls to be wary of.
Actually on Windows, I think the simplest change which would help all the issues
decribed in comment #3 would be to use GDI+
Having said that, I dont have benchmarks to know how much performance would
benefit (other than MS docs which say "programmers of new applications should
use GDI+ for all their graphics needs because GDI+ optimizes many of the
capabilities of GDI and also provides additional features"). At least it has
many of the algorithms and features Mozilla needs.
Of course, this doesnt help cross-platform performance or needs.
I'd like to mention that its not a good idea to start saying, "We'll fix this
with the OpenGL fix" for bugs like bug 98971 - on bilinear image scaling. This
bug isn't a small fix and will require a lot of testing. That's why I'm adding
the keyword "highrisk"
highrisk: Bugs whose fixes have a high level of risk associated with them,
typically due to some major architectural changes being required (see
the 'arch' keyword). Typically these are bugs that were deferred from the
previous release cycle due to the high level of risk involved, and should
therefore be fixed as soon as possible in the next cycle. Examples: "need to
rewrite handling of HTTP headers" or "need to redesign the content sinks".
If believe this bug could be considered a major architectural change since it
will change the way in which graphics are rendered throughout mozilla.
GDIPlus is probably not an option as it requires a download from Microsoft if
you are on Win95/98/ME/2k. I believe WinXP has it. Some documentation says 2k
has it, but it wasn't on my 2k machine.
Unless of course, it was a build option.
paper: couldn't moz ship with the gdi+ dll?
> Things that would likely work worse in OpenGL:
> . Text rendering (uh-oh)
We would rasterize glyphs ourselves and upload as textures. This is basically
what our existing Freetype code already does on X (both the bstell code and the
Xft code) --- except X is slower, of course.
> . Drawing to an offscreen image (double-buffering -- when
> you swap buffers in OpenGL the new backbuffer's contents
> become undefined.
Not a problem, we always throw the old buffer away anyway.
> Single-buffering would give flicker.
> Hardware-rendering to an offscreen pixmap is nonstandard.)
My OpenGL books are at home but I think they describe rendering to an offscreen
pixmap to do lots of tricks. Anyway the real issue is not whether it's standard,
but whether existing cards let us do it, and I'm pretty sure they do.
> . Screen-screen copies (scrolling!)
If OpenGL rendering is fast enough, we would just rerender the entire scrolled
area. We already do this for certain complex pages (e.g., pages with
I totally agree with Brian that OpenGL is not a solution to any short-term
problems. We need to keep improving our existing GFX implementations.
We could detect at runtime if GDI+ is available and use it if it is.
BTW Adam, rendering to offscreen pixmaps is necessary to do CSS/SVG transparency
properly as well as for double buffering, and one of my main motivations to use
OpenGL would be to speed up the rendering of exactly that sort of effect. So if
offscreen OpenGL rendering doesn't work well in common cases (say Linux+NVidia)
then I'm suddenly not interested in it anymore.
You're fine with the nVidia drivers on linux and windows.
I think the recommended way to do this on windows is with
the WGL_ARB_pbuffer extension. There's an equivilent (but
different) extension offered by recent nV drivers on both
platforms but the name escapes me.
One thing I should mention here is that on Linux, OpenGL with Direct Rendering
is a much faster path to the graphics hardware than the X protocol and the X
server. If there's a win here, it's probably bigger on Linux than anywhere else.
I'd like to add my vote for OpenGl for precisely the reason mentioned by Mr.
I started out by asking about Gtk/Qt use of DRI, and when I learned that only
OpenGL used DRI at the moment, searched for this bug.
It'd be nice to be able to scroll over a fixed background without stutteriness.
Or move a sidebar menu without it jumping around.
Mozilla under linux is a bit of an embarassment in terms of responsiveness.
People are quick to blame the mozilla code, but I bet it is just the windows
advantage of direct access to graphics card.
*note, I am in *no* way a graphics programmer or have any familiarity with it,
all the above is just the rantings of a user* :)
Anything ever come of this?
I think the idea is to switch to Cairo for (most?) rendering, and that gives
gecko a pretty good OpenGL back-end for free.
There don't seem to be any bugs in bugzilla about the Cairo support though,
which is mysterious. I guess if it's happening then it's happening offline.
The Cairo work is happening very slowly right now. It will speed up a lot once I
start working on it in January.
The overall plan here is to get Mozilla working using Cairo for all rendering on
all platforms. Then users with good OpenGL support can use the "Glitz" Cairo
backend to get hardware acceleration. This will require us to do some work on
Cairo itself to make it fast enough, but at least we won't be doing the graphics
layer alone anymore.
Does this bug still apply or can it be closed since we're using Cairo?
Created attachment 408683 [details] [diff] [review]
braindead opengl on OS X
Here is a patch that Vlad gave me, and I fixed up a little, that takes the output of Firefox's rendering on OS X and, on every draw, creates a texture, uploads it, and draws a textured quad.
Let me be clear: this is proof-of-concept only. It implements hardware deceleration. It is not the way we want to go. But it's at least a starting point.
This should be duped to something??
We have OpenGL layers now, implemented via other bugs.