[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Delay display of WebGL?
- To: Steve Baker <email@example.com>
- Subject: Re: [Public WebGL] Delay display of WebGL?
- From: Cedric Vivier <firstname.lastname@example.org>
- Date: Mon, 15 Nov 2010 00:08:14 +0800
- Cc: stephen white <email@example.com>, public webgl <firstname.lastname@example.org>
- 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=j8QUZGClUoXBlXYaEbye5mvP/H0FCoTKoHTAXVw3zY4=; b=CQtRoSwlxM7hgguFuLSk3dmbyKj4qHEkGWuS3A7SXoDqjuSSc++zcgHMPJ0PTQynfY GvnIqnCgwakAZ+ZGbnFJxKB3L9UL52X2w3oXkvcW6tquvVmLT5icJs0ec2jvZlpAQQzF pyoVZXjj96/2qhjTtsvvFp1bN068S8tSuE3ts=
- 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=xh8vlw2Kz+CjV8ct9v+syOw/j3x5bCZeRdRPYwUvzqvrXFl1xQNYvWQ3B9ZD0EjNll pQHfFkReiQi5oWCjYYCnLjwC+pb36qnpBYixJGPT817OwfXqNv30IqNf7cKfTS5Rrded dNJE2hepZkhHmzJKq7zP89VtJdMnJCJu2HecY=
- In-reply-to: <4CE0037F.email@example.com>
- References: <A0CA3A3D-D139-4E92-9F6D-D6E0236A4B14@adam.com.au> <4CE0037F.firstname.lastname@example.org>
- Sender: email@example.com
On Sun, Nov 14, 2010 at 23:42, Steve Baker <firstname.lastname@example.org> wrote:
> If not, then perhaps there is a case for adding a new timer event that
> only triggers when the tab is visible. Then application writers could
> use that event to trigger their draw() calls - and trigger the normal
> timer event for critical operations that don't generate graphics.
Yes, we discussed this at length few months ago :
Unfortunately nothing much came out of it iirc (?)... but there is
efforts outside of WebGL to add some kind of generic event that
triggers before frame rendering (mozOnBeforePaint? Vlad?)
IMHO adding another timer is more of a workaround than a long-term
solution, as it 'promotes' developing an app for a particular
framerate - something hard to do when the content can run on anything
from cellphones to high-end desktops.. so some problems would not be
fixed by this.
An API that promotes framerate-independence on the other hand would
solve most if not all the problems you pointed out, eg :
(which ultimately should be what a "onBeforePaint" event would do -
question is do we need something WebGL-pecific, I guess not)
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: