[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] How to handle partially failing getContext()



I would love to see that happening :) New drivers seem find their way
to end users machines about at the same speed as tectonic plates move.

Google Body Browser seems to overcome this problem by disabling writes
to alpha using color mask right after clear. I'll try that as short
term solution.


--mikko


On Wed, Jun 8, 2011 at 7:41 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
> The simple solution for now, always ask for an RGBA backbuffer?
>
> On Wed, Jun 8, 2011 at 1:20 AM, Mikko Mononen <mikko@tinkercad.com> wrote:
>>
>> Hi,
>>
>> Thanks, I'll have a look at the dev channel.
>>
>> Actually our issue seems to be pretty much exactly as described in
>> issue 82420: http://code.google.com/p/chromium/issues/detail?id=82420
>>
>> Unfortunately many very important people seem to have these GPUs :( I
>> will try to see if I can find some way around the issue until the
>> drivers get fixed and will check dev channel too.
>>
>>
>> --mikko
>>
>>
>> On Wed, Jun 8, 2011 at 10:57 AM, Vangelis Kokkevis <vangelis@google.com>
>> wrote:
>> >
>> >
>> > On Wed, Jun 8, 2011 at 12:24 AM, Mikko Mononen <mikko@tinkercad.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have been inspecting a bug in our app where Intel HD GPUs will just
>> >> render a black screen when using Chrome 12 in win7. Firefox seems to
>> >> blacklist this GPU.
>> >>
>> >> The problem is triggered by calling getContext() with 'alpha' attrib
>> >> set to false (I want opaque composition). In that case the
>> >> getContext() returns a valid context and sets webgl error to "invalid
>> >> argument". Any rendering with that context will result a black
>> >> rectangle on screen. If I set alpha to true, I can see that the
>> >> rendering is correct, but the composition is of course different too.
>> >>
>> >
>> > There was an issue we had discovered with some AMD gpus on recent macs
>> > that
>> > had the same symptoms.  It looks like what was happening was that even
>> > though we were asking for an RGB only backbuffer (a texture attached to
>> > an
>> > fbo in our case), the driver was allocating an RGBA buffer and the alpha
>> > channel values (initialized to 0) would prevent the WebGL content from
>> > showing up.  This was addressed for chrome with a change in the
>> > compositor:
>> > https://bugs.webkit.org/show_bug.cgi?id=61091
>> > which should be available in the current 13.x+ (Dev channel and Canary)
>> > releases.  You might want to give it another try there.
>> >
>> >
>>
>>
>>
>> --
>> Mikko Mononen, Software Engineer
>> http://tinkercad.com - Solid modeling for artists & makers
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>
>



-- 
Mikko Mononen, Software Engineer
http://tinkercad.com - Solid modeling for artists & makers

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------