objarni's picture

Unify GL.ClearColor/GL.Color3

Project:The Open Toolkit library
Version:0.9.1
Component:Code
Category:feature request
Priority:minor
Assigned:Unassigned
Status:won't fix
Description

* Since both ClearColor and Color3 allows the OpenTK app developer to specify a color (one the clear color, the other the current color), both should provide the same API interface to specify the color
* Right now one has 26 overloads, the other 2
* I don't know the correct overloads, but at least (Color),(double,double,double) and (byte,byte,byte) seems useful


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

#1

Uh, GL.ClearColor does not have any versions that accept pointers, while GL.Color does. Why is there any need for this? Rather suggest what overloads of GL.Color should be removed, I don't think there is any point adding more overloads to GL.ClearColor besides what we have? (How often you call it per program?)

the Fiddler's picture

#2

Status:open» won't fix

Agreed, I don't see the value in adding any more overloads to GL.ClearColor (between floats and System.Drawing.Color you have everything you need).

GL.Color3 is analogous to GL.Vertex3, GL.Normal3 etc. If we are to change one we'd have to change all, which would break compatibility without offering anything in return.

I'm closing this as wontfix:

  1. We shouldn't change a working api unless absolutely necessary.
  2. The cleanup will come with GL3 anyway.
objarni's picture

#3

It's not that big a deal - I am just trying to improve OpenTK, remember that.

The basic question is "why do they differt"? After all, both specify a color.

Fiddler: If you could just give me a good reason why they differ, I'd be satisfied. Saying Color3 is like Vertex3 Normal3 etc. is a bit odd - Isn't ClearColor more like Color3 than Color3 like Normal3?

Inertia: I'm not saying ClearColor should necessarily have more, nor that Color3 should necessarily have less. From a application developers standpoint, it is just _strange_ for two methods both accepting a *color* that they differ so much. And I've also put the issue as a "minor" issue.

the Fiddler's picture

#4

I don't know why SGI defined these functions this way, but I'm pretty sure they had a reason (and it probably made sense 15 years ago when they were speced).

If I had to guess, I'd say that Color[34], like Vertex[234] etc, would be used to load data from models stored on disk. People probably wanted to load the model into memory and let the driver handle the conversions as necessary (as opposed to manually converting the model data to floats).

On the other hand, ClearColor didn't need to be as convenient. Some programs are only going to call it once at startup. Most won't call it at all: games tend to render to the whole viewport, so they don't even call GL.Clear, while CAD programs usually have a simple black backdrop.

objarni's picture

#5

Thanks for that answer Fiddler, I did not know it was SGIs fault :)