[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?
- To: Steve Baker <email@example.com>
- Subject: Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Wed, 3 Nov 2010 22:06:47 -0700
- Cc: "Gregg Tavares (wrk)" <email@example.com>, Chris Marrin <firstname.lastname@example.org>, Vladimir Vukicevic <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288847210; bh=MQ/El/4UGWkxerNyvD6Nia8st5k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=uZnyrw4ba3Lhg6n5RdRLTcu2pXbAhwjCn+2ysMHtLyr5862JTyxopf2mXjmdgsl7p 7U09mk+M5onzJQ/zzGZAA==
- 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=hCw3SqD4p6jQ4/43hZ8FR5RT6fTYLAzIg1X3hC+Weco=; b=I64nLzT3rSK2SSJmzpN6bZbnTvLSXCzMRtXzoiRFbb504XNET/zcE/08zVttiKm3NR fyxE38uEH4sdTLl3AJ7w==
- 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=nAyN8a/6rMl1xZxevb0tAdknCuiCgdJdHC7Wq7Q57i36ivc4UG66MxffeWxx7HIjci xMDNlWEI001FPcORwywQ==
- In-reply-to: <4CD23DDE.email@example.com>
- References: <AANLkTi=rKRNuWGwfD39h5d6Ttu55paWSq9qTNQ19xfC5@mail.gmail.com> <1561074246.1142.1285141436615.JavaMail.firstname.lastname@example.org> <AANLkTin2iu-V1LckEs_YJCUFgwRWX4rPvy+Z8MnaGy5c@mail.gmail.com> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <AANLkTim-i8j4LrzDrWyi_djdSxpg0-j5igvRhK9DNSMj@mail.gmail.com> <4C9D395A.email@example.com> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <AANLkTi=rFt3apXrfwfxtcF47nZS+fKDRCXMmPRUfd0Ja@mail.gmail.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <AANLkTimutLit_273e5pg1e3fg7n-uQyPK1ZxoZenBj59@mail.gmail.com> <AFA5AA20-36D7-4B85-95CA-2BB520C59DEC@apple.com> <AANLkTimi-Zgq62B7GEnYR72qR+kkMgFzagbX=4PWM0Rt@mail.gmail.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <AANLkTikr5ZDtydmyTn+OLqbuut6uquVW6PW+2tM_btmR@mail.gmail.com> <4CA50820.firstname.lastname@example.org> <AANLkTinPNy0UKgGffNF67xM_8qn9vvq_5M4wUbP3hBmg@mail.gmail.com> <4CD23DDE.email@example.com>
- Sender: firstname.lastname@example.org
On Wed, Nov 3, 2010 at 10:00 PM, Steve Baker <email@example.com> wrote:
> On 11/03/2010 09:11 PM, Kenneth Russell wrote:
>> 1. Make the largest supported backing store, and stretch it to fit the
>> canvas's area on the web page. Add an API to WebGLRenderingContext,
>> "long getDrawingBufferSize()", returning the actual width and height
>> of the backing store.
>> 2. Set a synchronous error condition on the canvas which can be
>> checked via a new API such as "boolean isDrawingBufferValid()". Draw
>> calls either raise an error or are ignored.
>> 3. Raise a WebGL context lost event when the canvas is resized too
>> large, and a context restored event when it is shrunk back to a
>> supported size.
>> At this point I continue to believe that (1) is the best option for
>> web developers. Naive developers will get mostly correct results,
>> which based on discussion with Tab Atkins are better than no results.
>> I would no longer advocate (3) as it is too complex to handle. Raising
>> an exception from the setting of canvas.width or canvas.height does
>> not seem to be a viable option as it changes the semantics of these
>> I propose that we update the spec to indicate that WebGL
>> implementations do (1). Please send any comments to the list.
> Excellent! I agree.
> This way, you are rendering to a smaller surface than you asked for (and
> you can query the dimensions that you actually got) - and the resulting
> image will be stretched as necessary (presumably by the compositing
> software) to make it cover the area you actually asked for. But please,
> let's not try to automatically compensate with viewport dimensions and
> such. It should be up to the application to get that right by using the
> numbers returned by getDrawingBufferSize()
> Also, can the specification provide a guarantee that the aspect ratio of
> the reduced surface will be (to within reasonable hardware limits) the
> same as the application asked for? Some algorithms behave badly with
> non-square pixels.
> eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but
> there were only 320k pixels of storage available - then I should
> reasonably expect to get back an 800x400 buffer rather than a 640x512 or
> a 1024x320.
How would you define "reasonable hardware limits"? Having one
dimension be off by no more than one or two pixels from the ideal,
potentially fractional, value when preserving the aspect ratio? Off by
no more than a certain percentage? What about pathological cases of
very wide or very tall canvases?
I think we should keep it simple. No guarantees about preservation of
aspect ratio. If the app wants to do the right thing, the app should
query both getDrawingBufferSize and canvas.clientWidth/clientHeight
depending on the values needed.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: