[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: firstname.lastname@example.org
- Subject: Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?
- From: Cedric Vivier <email@example.com>
- Date: Mon, 8 Nov 2010 10:43:09 +0800
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=76FCqncuZI7JSlzHuT5Qi2Scxpq1yRfl0JFVYNUDS7s=; b=efFclp5owU2i0sDdKJTSQAmIZfLDaDcX7ds//JH6VCoQAFPA3DhSTSoceYCRfxAwGl Manbxic/b562vMOB6K11UuUD0AwJQ/vgvr/5dYwbfaOjIkBUgL9wWyXWSu+LsHdGcrqp 1aapKZ/DST/rh5AYtRPLrBcuhB7n/7UZZDwXk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=nJDY0TE1jlBhFdk2nTXE5hvsbajGFyji0ubg7D4TJ8HETPnJrv8ASdPXfBoG77XzQ8 Chx3ZMSZLnc1TWR9FOw66ruEeboQvpal8Aba5HA6yrkSYsADS0GOQbyHpctmqCB9hPMp rH2hAzKk6JHm4Q12lUzqPVzfCHqLIjT+3NCWA=
- In-reply-to: <1288995165.8512.2.camel@Nokia-N900-02-2>
- References: <1288995165.8512.2.camel@Nokia-N900-02-2>
- Sender: firstname.lastname@example.org
On Sat, Nov 6, 2010 at 06:12, <email@example.com> wrote:
> FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause.
> If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.)
If I understood correctly, the proposal is to also resize the back
buffer at new context creation (provided the host canvas is large
enough), which makes it a very reasonable analogy indeed.
I'm not sure how silently resizing a requested 10,000x500 canvas into
a 2048x500 will help in most cases, the rendering could be look very
different than what it was intended to be, nonwithstanding plenty of
other issues that may arise with some calculations, especially in
highly interactive WebGL content, because developer likely won't test
such aspect ratios.
For instance, outside of pure WebGL related issues, such a resize may
significantly change how mouse controls work if not taken into account
... typically relative mouse motion/position is given related to
canvas dimensions [manually or by libraries such as jQuery]. Even so,
handling it might make the application unusable anyways because of the
great loss in horizontal precision in rendering.
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: