Suggestion for lpImageData[123]D

According to Pipeline Newsletter 4, Image data will be defined using lpImageData[123]D, and that’s a very bad idea IMHO.

I propose using a single lpImageData signature. Since Image dimension is part of Image Format object, it is redundant to specify its dimension again. This would mean changing offset, width, height, depth to GLint* offsets and GLint* sizes.

Another point, I added an ‘index’ parameter to specify which cubemap face ( or array element ) are we dealing with. I believe this would be somewhat similar to the ‘target’ parameter in OpenGL 2.1.

This is the result:

    void lpImageData( LPimage image,
                      LPint index, // An integer, or: CUBE_POS_X, CUBE_NEG_X, CUBE_POS_Y, ...
                      LPint miplevel, 
                      LPint *offsets,
                      LPint *sizes,       
                      LPenum format,
                      LPenum type,
                      void* data )

It’s important to note that ‘index’ would be zero in most cases ( except for cubemaps and arrays ).

This would be cooler, more elegant, generic, lean & mean, KISS, whatever, IMHO.

If you guys find it absolutely necessary to specify a dimension on ImageData calls, I believe it’s a better idea to add a ‘dimension’ parameter instead of providing 3 (or more?) different functions:

      
    void lpImageData( LPimage image,
                      LPenum dimension, // 1D, 2D, 3D, ... could be an integer instead. It's another option.
                      LPint index, 
                      LPint miplevel,
                      LPint *offsets,
                      LPint *sizes,       
                      LPenum format,
                      LPenum type,
                      void* data )

Well, this is not really cool but would do the trick.

Gimme feedback please.

Sorry about the double post…

Best regards,
Daniel

This would be cooler, more elegant, generic, lean & mean, KISS, whatever, IMHO.
In what way?

Just because you can do something in 1 function doesn’t mean you should.

In the Longs Peak method, if it happens that there is a format mismatch between the image and the ImageData function, it simply throws an error. In your method, there’s no way to verify that the user is passing the right data until you get a mysterious seg-fault in GL code.

And that’s never a good thing.

Yeah, I’m not sure this is such a good idea. It’s already been reduce from 6 to 3 due to the removal of glTexSubImage, and possibly the removal of the glCompressed* functions (I don’t see any need for those if the implementation already know the image format).

So possibly 12 functions to 3, that’s pretty good.

Regards
elFarto

Originally posted by Korval:
[b]

In what way?

[/b]
To put it simply, there will be only one signature to be remembered. That impacts development in a number of different ways. Pick one.

Eg:

[b]
Just because you can do something in 1 function doesn’t mean you should.

In the Longs Peak method, if it happens that there is a format mismatch between the image and the ImageData function, it simply throws an error. In your method, there’s no way to verify that the user is passing the right data until you get a mysterious seg-fault in GL code. [/b]
Well, ppl can pass an invalid pointer in ‘data’ ( aka: smaller than specified ), so mysterious segfaults are not big news at all. Need not to mention all other LP functions with similar signature (eg: lpDrawxxx )

You didn’t say anything about the ‘index’ parameter. Any comments on that? Do you know how that’s currently specified in LP?

Regards,
Daniel

To put it simply, there will be only one signature to be remembered.
If remembering the signatures of 3 functions is too much for you, maybe you shouldn’t be programming. :rolleyes:

That impacts development in a number of different ways. Pick one.
Oh yes, that’s such an onerous impact. It’s so incredibly horrible to make some developers (in the “not-me” demographic) write a 12-line switch statement. :rolleyes:

Man, how lazy can you get?

Do you know how that’s currently specified in LP?
No; they haven’t told us. It’ll probably be specified in a reasonable fashion; whatever that might be.

Funny, I came across the same issue when I wrote a gl texture wrapper class, and I went for what daniel suggested. I found it easier to use (and also easier to implement). Less code, fewer bugs etc.

I agree with Daniel that it looks ‘cleaner’ and more generic.

If remembering the signatures of 3 functions is too much for you, maybe you shouldn’t be programming.
We’re talking about API design here. Generally, the ‘cleaner’ it is, the easier it is to use. I thought we were trying to move away from a bloated interface? Less code?

Well, ppl can pass an invalid pointer in ‘data’ ( aka: smaller than specified ), so mysterious segfaults are not big news at all.
Valid point.

On the other hand, I don’t know what the other object functions are like. I’d rather have 3 functions rather than one that breaks syntax consistency. It is also harder to debug for the user without specific error codes.

Generally, the ‘cleaner’ it is, the easier it is to use.
A function is not clean if it has a bunch of parameters that certain evocations of that function doesn’t use.

I thought we were trying to move away from a bloated interface?
And how is having a function for uploading to each kind of texture bloated? We’re not talking about the vast number of glVertex* calls here. It’s 3 functions.

Originally posted by remdul:
On the other hand, I don’t know what the other object functions are like. I’d rather have 3 functions rather than one that breaks syntax consistency. It is also harder to debug for the user without specific error codes.
Agreed. It will make debugging a bit harder. But since some other methods proposed in LP have similar problems ( eg: lpDrawxxx uses lots of arrays ), I find keeping the old glTexImage[123]D paradigm will break syntax consistency.

A function is not clean if it has a bunch of parameters that certain evocations of that function doesn’t use.

Well… On that matter, you can’t get any worse than the ‘lpDrawxxx’ functions, since they “combine multiple draw array and primitive instancing parameters into a single call”, according to Pipeline Newsletter 004. I personally like the idea.

Regards,
Daniel