write 2D graphic engine in GO? things like Skia,Cario

[Fino Meng]

is it possible to write 2D graphic engine in GO? things like Skia,Cario

GO want to replace C++, Skia is written in C++,

but Skia is compile to .so file.

I think for graphic libs, C is not very continent. C++ is too heavy,

GO is designed between C and C++,

but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,

then GO cannot replace C++, isn't it?

fino/

[Philipp Schumann]

Check out "gocos2d".

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?
fino/

[Archos]

A language with garbage collector is not going to replace to C++. In
change, Rust has been disegned to replace C++ and the main motivation on
its design was to build a browser engine based in Rust.

In the Rust community there are already several games developers, so you
should question in its mailing list.
http://www.rust-lang.org/

Here you have a MP2 decoder which was designed as a demo of the soft
real-time capabilities and safety features of Rust:

https://github.com/pcwalton/fempeg

Post by Philipp Schumann
Check out "gocos2d".

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?
fino/

[bryanturley]

Post by Archos
A language with garbage collector is not going to replace to C++. In
change, Rust has been disegned to replace C++ and the main motivation on
its design was to build a browser engine based in Rust.

What exactly about a garbage collector is bad for 2d graphics?

Or if we take it from another direction, this http://minecraft.com
EXTREMELY popular/successful game runs on top of a garbage collected
language (java).
So how does garbage collection prevent this?

In the Rust community there are already several games developers, so you

Post by Archos
should question in its mailing list.
http://www.rust-lang.org/
Here you have a MP2 decoder which was designed as a demo of the soft
https://github.com/pcwalton/fempeg

Whats with all the go haters hanging around here?

[Archos]

Post by bryanturley

Post by Archos
A language with garbage collector is not going to replace to C++. In
change, Rust has been disegned to replace C++ and the main motivation on
its design was to build a browser engine based in Rust.

What exactly about a garbage collector is bad for 2d graphics?
Or if we take it from another direction, this http://minecraft.comEXTREMELY popular/successful game runs on top of a garbage collected
language (java).

Sure, you can build in Go whatever simple game designed in Java.
But the author is also questioning about low level 2D/3D graphic libs and
C++ so my answer is telated to all that.

So how does garbage collection prevent this?

Post by bryanturley
In the Rust community there are already several games developers, so you

Post by Archos
should question in its mailing list.
http://www.rust-lang.org/
Here you have a MP2 decoder which was designed as a demo of the soft
https://github.com/pcwalton/fempeg

Whats with all the go haters hanging around here?

To be objective is fundamental to know choose the appropriate technology in
each case.

The next one is one of my accounts with open source wich has only Go code
and with more than 15 free Go projects. Am I a Go hater or somebody that
knows to choose the technology according to the project?
https://github.com/kless

[bryanturley]

Post by Archos

Post by bryanturley
Whats with all the go haters hanging around here?

To be objective is fundamental to know choose the appropriate technology
in each case.
The next one is one of my accounts with open source wich has only Go code
and with more than 15 free Go projects. Am I a Go hater or somebody that
knows to choose the technology according to the project?
https://github.com/kless

You just seem to point people towards rust a lot.
In this case for no reason, since nothing about go stops it from being
useful in this use scenario.
Nothing against rust but it already has a mailing list somewhere else.

[Archos]

Post by bryanturley

Post by Archos

Post by bryanturley
Whats with all the go haters hanging around here?

To be objective is fundamental to know choose the appropriate technology
in each case.
The next one is one of my accounts with open source wich has only Go code
and with more than 15 free Go projects. Am I a Go hater or somebody that
knows to choose the technology according to the project?
https://github.com/kless

You just seem to point people towards rust a lot.

I just to explain about be objective.

In this case for no reason, since nothing about go stops it from being

Post by bryanturley
useful in this use scenario.

In this case there is reason when OP believes that Go can be used to
replace to C++ and since the question is related to game developing, then I
can advise about a language suited for such task

Post by bryanturley
Nothing against rust but it already has a mailing list somewhere else.

That is the reason because I said to the OP tthat goes to questioning on
its ML.

[bryanturley]

Post by Archos

Post by bryanturley
In this case for no reason, since nothing about go stops it from being
useful in this use scenario.

In this case there is reason when OP believes that Go can be used to
replace to C++ and since the question is related to game developing, then I
can advise about a language suited for such task

I see go as perfectly viable for 2d/3d libraries and game development right
now, and as the compiler/runtime continues to mature it will only get
better.
Could you explain why go isn't suited for game developing, with substance?

[minux]

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?

1. Go doesn't mean to replace C++ (no other language has succeeded in
trying to do that:
as C++ still exists in mainstream).
2. Gccgo can generate .so file, and i think whether we have shared library
support or not
is not relevant to the question of whether one can write 2D graphics engine
in Go.
3. Why you think Go can't be used to write low level 2D/3D graphics
libraries or GUI widgets?
It seems you only give one reason (lack of shared library support).

[bryanturley]

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,

Not sure what you mean by continent but the worlds leading graphics library
(opengl) is written in C not C++.
I have never used skia but reading about briefly suggests that it can use
opengl as a back end.

[Fino Meng]

sorry I want to mean convenient, mainly for GUI/Windows/Widgets,

just want to have inside struct method, then we can use things like "
XXXbuttion.leftclick()"

in C , this is done by function pointers, which is not that direct u have
to find where is the really function in place.

but I didn't see inherit and polymorphic is really needed by
GUI/Windows/Widgets design.

Post by bryanturley

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,

Not sure what you mean by continent but the worlds leading graphics
library (opengl) is written in C not C++.
I have never used skia but reading about briefly suggests that it can use
opengl as a back end.

[bryanturley]

Post by Fino Meng
sorry I want to mean convenient, mainly for GUI/Windows/Widgets,
just want to have inside struct method, then we can use things like "
XXXbuttion.leftclick()"
in C , this is done by function pointers, which is not that direct u have
to find where is the really function in place.
but I didn't see inherit and polymorphic is really needed by
GUI/Windows/Widgets design.

You could use interfaces for the polymorphism and you don't absolutely need
inheritance for guis.

Post by Fino Meng

Post by bryanturley

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,

Not sure what you mean by continent but the worlds leading graphics
library (opengl) is written in C not C++.
I have never used skia but reading about briefly suggests that it can use
opengl as a back end.

[Gerard]

Post by Fino Meng
sorry I want to mean convenient, mainly for GUI/Windows/Widgets,

For the GUI part, you can take a look at https://github.com/mattn/go-gtk.
It's a quite impressive GTK+ wrapper.

[Fino Meng]

thanks, I will try it later,

but I want to know more if GO is suitable for write level graphic lib, lib
below GTK+, just above Linux driver (direct FB....)

it's job mostly done by C/C++ today.

the purpose to find new language to replace C++ is, C++ is difficult to
learn, and I need productive language than C,

the lib may not run on normal linux, but very custom and modified kernel,
for embedded system.

Fino/

Post by Gerard

Post by Fino Meng
sorry I want to mean convenient, mainly for GUI/Windows/Widgets,

For the GUI part, you can take a look at https://github.com/mattn/go-gtk.
It's a quite impressive GTK+ wrapper.

[Nigel Tao]

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario

Freetype-Go comes with a vector rasterizer. It does cubic Béziers,
similar to Skia or Cairo.

$ go get code.google.com/p/freetype-go/raster
$ go run code.google.com/p/freetype-go/example/raster/main.go
Wrote out.png OK.

[d***@public.gmane.org]

I am also interested in game development in Go.
We are already doing games in Lua and Python... so why not? Although the
mark-and-sweep garbage collector might be a problem.

I know there are a couple of SDL and Allegro bindings... but is there
anything specifically designed for Go ? Any idiomatic frameworks?

[Dougx]

There are a few mostly abandoned efforts like:
https://github.com/Urmel/Go2D
https://github.com/runningwild/glop
https://github.com/vova616/GarageEngine

The last of these looks like it's still moderately alive and maybe usable:

The issue is that most of these rely heavily on C or C++ backends and go
bindings, which in itself is fine, but they're usually not portable (or
only as portable as the base library).

I know there was some talk on the SDL mailing list a while ago about an SDL
binding for go, but I've only seen these ones that are based on SDL 1.2,
which you don't want to use:
https://github.com/banthar/Go-SDL
https://github.com/0xe2-0x9a-0x9b/Go-SDL

As for 'purely in go' --> No.

There's not even a proper cross platform GL binding, never mind GLES. If
you want to write a game in GO,

https://github.com/banthar/Go-SDL + https://github.com/banthar/gl Is
probably as good as it gets.

...and it's not very cross platform, just as a warning.

"Why should you not use go to write games?"

No reason. ...but if you're just writing a go wrapper around a tonne of C
and C++ code, why bother? Just write the whole thing in C++ instead. I'm
extremely dubious that keeping two code bases (including go as one) will be
more productive that one non-go code base. Perhaps. Depends how much of
your logic has to dip down into the C layer. I suspect a lot.

Without a graphics library as part of the core package, I just don't think
it's worth it.

~
Doug.

Post by d***@public.gmane.org
I am also interested in game development in Go.
We are already doing games in Lua and Python... so why not? Although the
mark-and-sweep garbage collector might be a problem.
I know there are a couple of SDL and Allegro bindings... but is there
anything specifically designed for Go ? Any idiomatic frameworks?

[bryanturley]

Post by Dougx
No reason. ...but if you're just writing a go wrapper around a tonne of C
and C++ code, why bother? Just write the whole thing in C++ instead. I'm
extremely dubious that keeping two code bases (including go as one) will be
more productive that one non-go code base. Perhaps. Depends how much of
your logic has to dip down into the C layer. I suspect a lot.

So far from what I can tell you will only need a little cgo for windowing,
opengl, audio and input.

Post by Dougx
Without a graphics library as part of the core package, I just don't think
it's worth it.

What viable hardware supported graphics libraries exist in reality?
OpenGL - c
Direct3D - c++ (maybe c as well?)
Everything else I can think of is a software renderer or just layers on top
of those two.

By your logic you couldn't write a game in anything but c/c++
Yet many people successfully write games in many other languages today.

Games are being sold that run in emulators on all the major home consoles,
that has to be the worst possible performance scenario yet they are also
successful.
Yes they are generally older, but people are still enjoying them despite
their diminished performance.

Most of the code in games is the actual game.
Drawing/audio/input aren't the entire picture.

[Dougx]

Sure.

Virtually every game that is not written in a c based language exists
because the "language" layer has a smart wrapper around the core that
provides an easy to use API.

Panda3D is python wrapped around c++
Moai, Love, Corona are lua wrappers around c++
Unity is a js/c#/boo wrapper around a c++ core
etc. etc.

If a wrapper like this *already existed* for go, then sure, it'd be a great
platform to use.
...but it doesn't. That means you have to *write one* if you want to write
a game in go.

I just don't think its a really compelling use case for go at the moment.

~
Doug.

Post by bryanturley

Post by Dougx
No reason. ...but if you're just writing a go wrapper around a tonne of C
and C++ code, why bother? Just write the whole thing in C++ instead. I'm
extremely dubious that keeping two code bases (including go as one) will be
more productive that one non-go code base. Perhaps. Depends how much of
your logic has to dip down into the C layer. I suspect a lot.

So far from what I can tell you will only need a little cgo for windowing,
opengl, audio and input.

Post by Dougx
Without a graphics library as part of the core package, I just don't
think it's worth it.

What viable hardware supported graphics libraries exist in reality?
OpenGL - c
Direct3D - c++ (maybe c as well?)
Everything else I can think of is a software renderer or just layers on
top of those two.
By your logic you couldn't write a game in anything but c/c++
Yet many people successfully write games in many other languages today.
Games are being sold that run in emulators on all the major home consoles,
that has to be the worst possible performance scenario yet they are also
successful.
Yes they are generally older, but people are still enjoying them despite
their diminished performance.
Most of the code in games is the actual game.
Drawing/audio/input aren't the entire picture.

[bryanturley]

Post by Dougx
Sure.
Virtually every game that is not written in a c based language exists
because the "language" layer has a smart wrapper around the core that
provides an easy to use API.
Panda3D is python wrapped around c++
Moai, Love, Corona are lua wrappers around c++
Unity is a js/c#/boo wrapper around a c++ core
etc. etc.
If a wrapper like this *already existed* for go, then sure, it'd be a
great platform to use.
...but it doesn't. That means you have to *write one* if you want to write
a game in go.
I just don't think its a really compelling use case for go at the moment.
~
Doug.

So if your lazy go is not a good language to write games in is what your
really saying.
I can see that point of view.

[chris dollin]

Post by bryanturley
So if your lazy go is not a good language to write games in is what your
really saying.

Not constructive, reads like a personal attack. Please
don't do that.

Chris

[Glenn Brown]

https://github.com/banthar/Go-SDL + https://github.com/banthar/gl Is probably as good as it gets.
...and it's not very cross platform, just as a warning.

I've had great luck with https://github.com/banthar/gl , but Go-SDL is broken on many architectures, including MacOSX. The problem is that SDL provides its own main() function in the library on many architectures, which is *ridiculous* interface design. In theory, Go-SDL might be able to work around this, although it shouldn't have to. Consequently, Go-SDL works only on Linux, AFAIK.

--Glenn

[Erwin]

Post by Glenn Brown
I've had great luck with https://github.com/banthar/gl , but Go-SDL is
broken on many architectures, including MacOSX. The problem is that SDL
provides its own main() function in the library on many architectures,
which is *ridiculous* interface design. In theory, Go-SDL might be able to
work around this, although it shouldn't have to. Consequently, Go-SDL
works only on Linux, AFAIK.
Go-SDL works fine on OS X as well, and so it does on Windows, i believe.

[Fino Meng]

thanks for kind reply,

I want to find language more productive than C , easy to understand than
C++,

compiled, can do level graphic lib and make embedded system only contains C
and this language,

maybe Object-C likes very fit :)

Fino/

Post by Dougx
https://github.com/Urmel/Go2D
https://github.com/runningwild/glop
https://github.com/vova616/GarageEngine
http://youtu.be/iMMbf6SRb9Q
The issue is that most of these rely heavily on C or C++ backends and go
bindings, which in itself is fine, but they're usually not portable (or
only as portable as the base library).
I know there was some talk on the SDL mailing list a while ago about an
SDL binding for go, but I've only seen these ones that are based on SDL
https://github.com/banthar/Go-SDL
https://github.com/0xe2-0x9a-0x9b/Go-SDL
As for 'purely in go' --> No.
There's not even a proper cross platform GL binding, never mind GLES. If
you want to write a game in GO,
https://github.com/banthar/Go-SDL + https://github.com/banthar/gl Is
probably as good as it gets.
...and it's not very cross platform, just as a warning.
"Why should you not use go to write games?"
No reason. ...but if you're just writing a go wrapper around a tonne of C
and C++ code, why bother? Just write the whole thing in C++ instead. I'm
extremely dubious that keeping two code bases (including go as one) will be
more productive that one non-go code base. Perhaps. Depends how much of
your logic has to dip down into the C layer. I suspect a lot.
Without a graphics library as part of the core package, I just don't think
it's worth it.
~
Doug.

Post by d***@public.gmane.org
I am also interested in game development in Go.
We are already doing games in Lua and Python... so why not? Although the
mark-and-sweep garbage collector might be a problem.
I know there are a couple of SDL and Allegro bindings... but is there
anything specifically designed for Go ? Any idiomatic frameworks?

[Ethan Burns]

Hi Fino,

I maintain a plotting library for Go called Plotinum
(code.google.com/p/plotinum); it includes a fairly small vector graphics
package named vg. Vg is really just an interface that sits on top of svgo
for SVGs, draw2d for PNG and other raster images, gopdf for PDFs, and a
custom encapsulated Postscript generator. For a GUI toolkit, you probably
want OpenGL support. Currently, vg does not support OpenGL, but an OpenGL
back-end could probably be added fairly easily.


Best,
Ethan

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?
fino/

[Sean Russell]

I maintain a plotting library for Go called Plotinum (
code.google.com/p/plotinum); it includes a fairly small vector graphics
package named vg. Vg is really just an interface that sits on top of svgo
for SVGs, draw2d for PNG and other raster images, gopdf for PDFs, and a
custom encapsulated Postscript generator. For a GUI toolkit, you probably
want OpenGL support. Currently, vg does not support OpenGL, but an OpenGL
back-end could probably be added fairly easily.

And thanks for that, by the way. Plotinum is one of my go-to libraries.

--- SER

[Fino Meng]

thanks for kind reply,

I hope I can find time to study the code in this month:)

Fino/

Post by Ethan Burns
Hi Fino,
I maintain a plotting library for Go called Plotinum (
code.google.com/p/plotinum); it includes a fairly small vector graphics
package named vg. Vg is really just an interface that sits on top of svgo
for SVGs, draw2d for PNG and other raster images, gopdf for PDFs, and a
custom encapsulated Postscript generator. For a GUI toolkit, you probably
want OpenGL support. Currently, vg does not support OpenGL, but an OpenGL
back-end could probably be added fairly easily.
Best,
Ethan

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?
fino/

[ajstarks]

Here is a high-level 2D library built on OpenVG for the Raspberry Pi:

http://github.com/ajstarks/openvg
http://godoc.org/github.com/ajstarks/openvg
http://www.flickr.com/photos/ajstarks/sets/72157630913689774/
http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html

Post by Fino Meng
is it possible to write 2D graphic engine in GO? things like Skia,Cario
GO want to replace C++, Skia is written in C++,
but Skia is compile to .so file.
I think for graphic libs, C is not very continent. C++ is too heavy,
GO is designed between C and C++,
but if we cannot use GO to write low level 2D/3D graphic libs, and GUI
widgets,
then GO cannot replace C++, isn't it?
fino/

[Job van der Zwan]

Post by ajstarks
http://github.com/ajstarks/openvg
http://godoc.org/github.com/ajstarks/openvg
http://www.flickr.com/photos/ajstarks/sets/72157630913689774/
http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html

Cool, did you announce that last year? Must have missed it...

BTW, and a bit offtopic: what are your thoughts on this development in
hardware accelerated vector graphics?
https://developer.nvidia.com/gpu-accelerated-path-rendering
I think it's pretty exciting - it's kinda weird that hardware support for
2D graphics seems to lag behind support for 3D graphics.

[bryanturley]

Post by Job van der Zwan

Post by ajstarks
http://github.com/ajstarks/openvg
http://godoc.org/github.com/ajstarks/openvg
http://www.flickr.com/photos/ajstarks/sets/72157630913689774/
http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html

Cool, did you announce that last year? Must have missed it...
BTW, and a bit offtopic: what are your thoughts on this development in
hardware accelerated vector graphics?
https://developer.nvidia.com/gpu-accelerated-path-rendering
I think it's pretty exciting - it's kinda weird that hardware support for
2D graphics seems to lag behind support for 3D graphics.

3D hardware can be used for 2D, it is just not as hyped as 3D.
People just normally do the 2D stuff on the main cpu to make it more
portable, and in the past to not tie up video device resources.

[Job van der Zwan]

Post by bryanturley
3D hardware can be used for 2D, it is just not as hyped as 3D.
People just normally do the 2D stuff on the main cpu to make it more
portable, and in the past to not tie up video device resources.

If I understood the presentation by NVidia correctly, the current solutions
- including hardware acceleration - have a lot of room for improvement,
both in terms of performance and in graphical fidelity (an example being
conflating coverage - bad seams). From the FAQ[1]:

If you play with the nvpr_svg example in the NVprDEMOs.zip, you’ll find

Post by bryanturley
that NV_path_rendering is typically many times (in a few cases even 100x
faster) than other well-known path renderers. This includes even includes
Direct2D.

[1]
http://developer.download.nvidia.com/assets/gamedev/files/NV_path_rendering_FAQ.pdf
(second-to-last page)

[bryanturley]

Post by Job van der Zwan

Post by bryanturley
3D hardware can be used for 2D, it is just not as hyped as 3D.
People just normally do the 2D stuff on the main cpu to make it more
portable, and in the past to not tie up video device resources.

If I understood the presentation by NVidia correctly, the current
solutions - including hardware acceleration - have a lot of room for
improvement, both in terms of performance and in graphical fidelity (an
If you play with the nvpr_svg example in the NVprDEMOs.zip, you’ll find

Post by bryanturley
that NV_path_rendering is typically many times (in a few cases even 100x
faster) than other well-known path renderers. This includes even includes
Direct2D.

[1]
http://developer.download.nvidia.com/assets/gamedev/files/NV_path_rendering_FAQ.pdf(second-to-last page)

These graphics devices used to have a lot of fixed functionality back in
the 90s early 2000s, if you strayed from this fixed functionality you had
to use the main cpu instead.
Now they are mostly just a whole bunch of almost general purpose FPUs and
memory controllers, with a few exceptions (2d/3d texturing hardware is the
only thing that comes to mind).
They didn't have to change the hardware to implement it, they probably just
wrote a few shaders and execute them through the api behind the scenes.
Something they couldn't have done say <= ~2004* on mainstream hardware.

* I can't remember when opengl shaders hit the almost general purpose level.

[Job van der Zwan]

Post by bryanturley
These graphics devices used to have a lot of fixed functionality back in
the 90s early 2000s, if you strayed from this fixed functionality you had
to use the main cpu instead.
Now they are mostly just a whole bunch of almost general purpose FPUs and
memory controllers, with a few exceptions (2d/3d texturing hardware is the
only thing that comes to mind).
They didn't have to change the hardware to implement it, they probably
just wrote a few shaders and execute them through the api behind the scenes.
Something they couldn't have done say <= ~2004* on mainstream hardware.
* I can't remember when opengl shaders hit the almost general purpose level.

Well, it's not 'just a few shaders', they've implemented all standards for
path rendering in a new OpenGL extension now retro-actively supported on
any CUDA-capable NVIDIA hardware. The point about programmability of GPUs
still stands of course.

Point is: if this is something that now works for NVIDIA cards from all the
way back to 2006, it's kind of disappointing that it took this long to be
implemented, don't you think? Especially since most computers spend more of
the time rendering 2D graphics than 3D.

But this is getting awfully off-topic.