[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
Am Mi, 19.05.2010, 19:24, schrieb Chris Marrin:
> On May 18, 2010, at 3:42 PM, Johannes Behr wrote:
>> On 18 May 2010, at 23:28, Chris Marrin wrote:
>>> On May 18, 2010, at 1:31 PM, Johannes Behr wrote:
>>>>> ...In thinking about this some more, I agree with Cedric and Gregg that
>>>>> returning the actual format is not really necessary. If we're able to
>>>>> support gl.NONE (or some custom enum as Mark suggests) as an
>>>>> internalformat and it loads the image in the original source format, I
>>>>> think that satisfies the requirements of X3DOM. So I think we should
>>>>> eliminate getTexLevelParameter() and just add internalformat to
>>>>> texImage2D() and add an enum which allows us to add the image in the
>>>>> original format.
>>>> The difference is, that we can not query anymore but must give the
>>>> "internalFormat" with every texture. Correct ?
>>> I don't think it's any different. You would always pass NO_CONVERSION (or
>>> whatever we end up calling it), which would use whatever was the input
>> But how could we know what the format was?
>>> I think that would do the same thing that X3D does today. There's no
>>> additional X3D requirement to know what the format is, right?
>> Again: The lighting model works different if you have e.g. L/LA or RGB/RGBA
>> as input format.
>> We can easily live with everything converted to RGB(A) as long as we know
>> what the format was
>> to select the right shader.
> This is where things get problematic. If we provide a mechanism to convert to
> the desired internalformat, without the NO_CONVERT option, most authors have
> all the information they need. They can force the format they want, regardless
> of the input format, and write their shaders accordingly. It might be better
Considering that only 8 bit textures are available and no floating point/
depth precision can be forced, the internalFormat param might more or less
only be interesting for transparencies and the aforementioned texture memory
But querying the original image format can have different use cases,
particularly in the web, where data can originate from everywhere...
> to just provide the explicit conversion options (without NO_CONVERT) and then
> come up with a different method of discovering the image formats. You should
> be able to determine the basic image type from the mime-type, right? In the
> case of JPG, this defines the format. Is there any way to use XHR to read the
No, JPG can also be e.g. LUMINANCE.
> header of a PNG image and read the format tag from that?
I don't know if it's possible at all, but retrieving the image via XHR (or
only the header, which I doubt is possible) seems to be a big overhead
concerning bandwidth and processing power since the browser has to fetch the
> You are currently subscribe to email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
Fraunhofer-IGD | Tel.: ++49-6151-155-290
Fraunhoferstr. 5 | Fax.: ++49-6151-155-196
64283 Darmstadt | email: email@example.com
Germany | http://www.igd.fhg.de/igd-a4
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: