Call for orthogonality

OpenGL
1

I don’t know if this makes sense to the majority, but I have felt a serious lack of orthogonality in the openGL API as of lately.

I’m not thinking of extensions here (e.g. FBO) but core stuff.

glBitmap? Only for FB. Why not the current 2D texture? It’s slow (as hell) doing the same thing to texture.

Texture copy operations? Why forcing us to first copy to FB and then to another texture when a texture-to-texture copy would be optimal (all on the server)? What about copy sub-rect (64,64)-(192,192) from one texture to (0,0) on another texture of size(128,128)?

Simplified copy operations for pixel transfers. I want one set having NO transformations and/or pixel operations, and the other working as they do today (to not mess up the spec).

Better pixel-coordinate-specifications for the operations that need it. 2D op’s should be easy, not a bitch.

A new mode (perhaps), to flip ‘y’ for pixel op’s. All, and I do mean all 2D pixel API’s I know of uses top-left coordinate system. It’s the only thing that really makes sense on computers, knowing CRT sweeps. Wouldn’t it then be reasonable for OpenGL to also have

Make it possible to copy both from FB and from another texture “upside-down”. Currently, if you have a texture in one y-direction, and you for some reason need it upside-down, you need to:

  1. Render it as a quad to FB.
  2. Copy it to the FB but upside-down to another place.
  3. Read the texture from that place.

Why not simply allow PixelZoom for a new texture operation?

These are jusr a few of my current gripes, but hopefully enough to get a discussion stared. OpenGL has IMO stagnated (for both good and bad), but this is an area it needs to attend to.

2

Why forcing us to first copy to FB and then to another texture when a texture-to-texture copy would be optimal (all on the server)?
Because operations are only possible on the bound texture. And there is only ever one at any one time. This is the API derived from an environment when there was only ever one texture period, and there were no texture objects.

BTW, such copy operations aren’t exactly in high demand at the moment.

And, technically, we have this operation now with FBO.

What about copy sub-rect (64,64)-(192,192) from one texture to (0,0) on another texture of size(128,128)?
Because that’s a blitting operation that can easily require:

1: a format conversion of the source data
2: using the CPU to do the copy because of 1 or:
3: binding the destination texture as the framebuffer and rendering to it.

Since 3 is quite possible today, just use 3.

I have felt a serious lack of orthogonality in the openGL API as of lately.
It seems more like you’re trying to do 2D operations counter to how OpenGL wants to do them.

I understand your pain, but you are asking to do 2D operations on a platform designed for 3D rendering. You can’t expect to get top priority.

3

What’s wrong with rendering a textured quad into an FBO? Together with fragment shaders this is by far the most general texture-to-texture blitting operation I can imagine. You can do much more than just flip the Y axis with this method :wink:

There is no point in exposing much less general API, because everything you ask can already be done with OpenGL + FBO. It’s just not as easy as you might wish, but here the same argument like e.g. against a glDrawCube function applies. Shortcut functions for special use cases are the job of higher level APIs…