[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: "Gregg Tavares (wrk)" <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: Thu, 4 Nov 2010 17:13:47 -0700
- Cc: Cedric Vivier <email@example.com>, Steve Baker <firstname.lastname@example.org>, Chris Marrin <email@example.com>, Vladimir Vukicevic <firstname.lastname@example.org>, public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288916030; bh=ESTFyKeTV90KnR11Vn/ztZSs/Q0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Spqe+AijVUdYZgcC7lo7jrGpN5tWu+PwRVa28JqfJv7Id5T8Ux7sa5TAv0AV92N5o 7eLAD5xhnv/l40tSSICjA==
- 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=FJIN8jeWced17c4NUlsttWlD517W7x2PiwmynN+zkrE=; b=vPJCK1pmdY+TAMVDHEao9WlHigSok7KMQ5HFme33972tYGY+zFHTocN1wJ0ULk43zo mRL9dRLyXkNgTI6BKDbw==
- 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=k2J+eCjv1YdCdPlE49Z+k7Rh6ER8sVuOrLrwP4gBBurERSRUjgxNKiv3I6OStcTqw2 aTo677WzoooJ59CFTnKQ==
- In-reply-to: <AANLkTinkLrJnCnOjR8mgyuP817Z-u5t8m6mtNiRxk5Lz@mail.gmail.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> <AANLkTimN5UQY3+dFFQ_=NYr-bJbWUvaRZmiEssGN8y9P@mail.gmail.com> <AANLkTinkLrJnCnOjR8mgyuP817Z-u5t8m6mtNiRxk5Lz@mail.gmail.com>
- Sender: email@example.com
On Thu, Nov 4, 2010 at 2:05 AM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
> On Wed, Nov 3, 2010 at 11:17 PM, Cedric Vivier <email@example.com> wrote:
>> On Thu, Nov 4, 2010 at 10:11, Kenneth Russell <firstname.lastname@example.org> wrote:
>> > On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker <email@example.com> 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.
>> I'm not sure I like this approach, this is a bit too implicit imho.
>> Setting or manipulating any variables/arguments related to drawing
>> buffer dimensions (viewport, scissor, readPixels) would then need to
>> use the values returned by this new function to give correct behavior
>> in all cases.
>> However it is highly unlikely imho that most developers would use it
>> this new function everywhere it would be need for consistent behavior
>> in case of downsizing. Indeed, canvas.width and canvas.height are the
>> most intuitive/easiest/straightforward/canvas2d-like way to do it and
>> not using this new function would never show any issue except in the
>> rare(?) cases when the WebGL implementation has to downsize the
>> backing store.
>> IMHO backing store resizing should be an implementation detail that
>> the developer does not have to think about, I propose another option :
>> 4) At context creation, the WebGL implementation might setup a drawing
>> buffer with different dimensions than the canvas, *provided that the
>> dimensions have the same aspect ratio than the canvas*.
>> Internally, the scale ratio (1.0 by default) is used to "correct"
>> width/height input arguments given to viewport, scissor, and
> If I have a 9 monitor setup and I stretch the window across all 9 1280x1024
> monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer?
> That doesn't seem like the result I want. Most of the time I want the
> largest resolution I can get.
> If your app needs a 1.0 scale ratio then query the max backbuffer size and
> then set the size of the canvas appropriately. Only about 4 of the last 60
> 3d apps I've written would have needed this. Most of my apps in WebGL pick a
> fixed backbuffer size and let the canvas scale automatically.
> It seems like it's better to do the best thing for the majority of apps.
> Those few apps that need a 1.0 scale ratio can do what they need to force
I agree. The majority of the 3D applications and demos I've written
handled resizing the window to arbitrary sizes, and adjusted the
projection matrix as necessary.
Requiring that the aspect ratio of the canvas's width and height be
preserved goes against the OpenGL philosophy that the APIs have as
little mechanism behind them as possible. We've adhered to this
philosophy in other areas such as not automatically adjusting the
viewport when the canvas is resized.
>> We might provide a "float getDrawingBufferScale()" API to expose that
>> information, could be useful to load lower resolution textures for
>> instance, however this is not necessary for correct and consistent
>> behavior whether or not the buffer has been scaled... in fact we
>> probably should not expose this information at all.
It is absolutely necessary for certain applications to understand the
precise dimensions of the back buffer, for example so they can make
correct glViewport calls.
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: