[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] GL error on startup.
- To: Steve Baker <email@example.com>
- Subject: Re: [Public WebGL] GL error on startup.
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Mon, 20 Dec 2010 12:18:00 -0800
- Cc: public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292876282; bh=ROyy9WZKt2bp9+kSDEuL0JJlr1I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=UCmewZcXtyDczVKSZWDj/PbUGLmpgN4Sg7rnqY22GojrhDTqQWB0Djq2CkwcoS54i s+IOFz5Ir7guoLZjLeEGg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4ySTr2bS9UGAhjNym1TfdaZMtqIiTmqJeHLg1VlG6+s=; b=iSX4yZzV/7FKrfSF0LISx6LEGQ08RyNRhbXSTCfyEO4/3QILWGr7/T+vrs3fdEKZED gtROsAnxQ0SWnO2v+Chw==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qdO+lJnQU3FhQVSooQE5dAKTHwQaYuQwDrucMyRDd5GNd8AA2xT0KhZqccOOTEbefO Qm3fgjt6M9A9L8fY9bQg==
- In-reply-to: <4D0FBB14.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4D0D8ADC.email@example.com> <AANLkTiksXAXVN1mK+25ms6xE4-kXpQmwamu95ao23Eofirstname.lastname@example.org> <4D0FBB14.email@example.com>
- Sender: firstname.lastname@example.org
On Mon, Dec 20, 2010 at 12:22 PM, Steve Baker <email@example.com> wrote:
> On 12/20/2010 12:42 PM, Kenneth Russell wrote:
>> On Sat, Dec 18, 2010 at 8:32 PM, Steve Baker <firstname.lastname@example.org> wrote:
>>> On my son's EeePC netbook (which has some god-awful Intel processor) -
>>> using Chrome/ANGLE - I'm getting a GL "Invalid Operation" error right after:
>>> var gl = canvas.getContext ( "experimental-webgl",
>>> alpha : false ,
>>> antialias : true ,
>>> depth : true ,
>>> stencil : false ,
>>> premultipliedAlpha: false } ) ;
>>> ...but it's returning a non-null value for "gl" and if I clear the error
>>> - everything seems to run OK. I don't see this problem on other systems.
>>> I thought these parameters were just advisory - there shouldn't be any
>>> illegal values -right? Sure the machine doesn't support antialiassing
>>> - but it's OK to ask...right?
>> Yes, this sounds like a bug. Does it also happen if you pass the
>> command line argument --use-gl=desktop ? If not, please file a bug
>> with the ANGLE project -- sounds like a GL error is being synthesized
>> when it shouldn't be. Otherwise, please file a bug at
>> http://crbug.com/ and CC: kbr at chromium.org.
> This netbook doesn't have OpenGL support (crappy Intel chipset only
> supports OpenGL 1.2!)...so we can't do that test.
I see. Well, feel free to log bugs against both projects and point
each to the other bug. We'll probably have to make them low priority
but if we can get our hands on similar hardware can try to track down
where the error is being synthesized.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: