[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proper way of rendering only when something changes



Disabling accelerated compositing is not a good workaround. The
direction that Chrome is going is to use accelerated compositing all
the time, so it would be best to get to the bottom of the issue.

Please create a small test case and file a bug at
http://new.crbug.com/ . Feel free to post the bug ID here to make sure
it gets noticed.

-Ken


On Mon, Jun 4, 2012 at 11:50 PM, Mikko Mononen <mikko@tinkercad.com> wrote:
>
> Hi,
> Yes, canary build has the same problem too. I have now made a hot fix
> on the site, so the problem does not appear there anymore.
> If I run Chrome without hardware comp, it seems to work: open -a
> "Google Chrome Canary" --args --disable-accelerated-compositing
>
> --mikko
>
>
> On Mon, Jun 4, 2012 at 8:11 PM, Gregg Tavares (çç) <gman@google.com> wrote:
>> Does the problem happen on Chrome Canary?
>> https://tools.google.com/dlpage/chromesxs
>>
>>
>>
>>
>> On Mon, Jun 4, 2012 at 12:27 AM, Mikko Mononen <mikko@tinkercad.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I'm still waiting for confirmation on the FF bug, this might actually
>>> be Chrome bug. Sorry for communicating otherwise.
>>>
>>> Here's a quick JSfiddle to show how our rendering looks like:
>>> http://jsfiddle.net/MikkoMononen/S2vt8/2/
>>>
>>> Unfortunately that example does not trigger the bug, but it should
>>> give and idea what I'm doing. I have to see if rendering something
>>> will actually trigger the situation (where's imm mode when you need
>>> it!).
>>>
>>> If I disable draw2() in our codebase or move call to draw2() it to the
>>> beginning of draw(), the problem goes away.
>>>
>>> So it looks like that if the last thing I did was to render to an
>>> off-screen buffer and then the browser needs to render/composite the
>>> page again (sorry my understanding of dom/render/composite updates is
>>> a bit vague here), the WebGL canvas is rendered blank.
>>>
>>> Adding preserveDrawingBuffer does not help.
>>>
>>>
>>> --mikko
>>>
>>>
>>> On Sun, Jun 3, 2012 at 11:51 AM, Ilmari Heikkinen
>>> <ilmari.heikkinen@gmail.com> wrote:
>>> > Hi Mikko,
>>> >
>>> > In what cases does the unprompted WebGL canvas clearing occur? Do you
>>> > have a minimal testcase and/or more details about the hardware setup
>>> > of your users.
>>> >
>>> > The only canvas-clearing DOM thing that I'm aware of is setting the
>>> > canvas element width and height attributes. If the clearing happens on
>>> > CSS changes or changing unrelated elements, it sounds like a browser
>>> > bug so all details would be appreciated.
>>> >
>>> > Thanks,
>>> > Ilmari
>>> >
>>> >
>>> > 2012/6/1 Mikko Mononen <mikko@tinkercad.com>:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Are there some general guidelines how to build a render loop where the
>>> >> app only draws the scene when something changes? Pretty much all the
>>> >> samples out there render in an infinite loop.
>>> >>
>>> >> Our app currently renders only when something changes to save the
>>> >> precious battery and fans. We're getting increasing amount of reports
>>> >> from the users using bleeding edge Firefox or Chrome that rendering
>>> >> does not work for them anymore. If we render stuff with infinite loop
>>> >> using requestAnimationFrame(), everything works, but once rendering
>>> >> only when stuff changes, the WenGL canvas is cleared when any element
>>> >> state changes in DOM, i.e. hover changes element appearance of a
>>> >> button.
>>> >>
>>> >> My diagnosis is a bit Chrome specific, but since we're getting similar
>>> >> reports from FF users too, I'm worried that I'm missing something more
>>> >> general.
>>> >>
>>> >>
>>> >> --mikko
>>> >>
>>> >>
>>> >> --
>>> >> Mikko Mononen, Software Engineer
>>> >> http://tinkercad.comÂ- Solid modeling for artists & makers
>>> >>
>>> >> -----------------------------------------------------------
>>> >> You are currently subscribed to public_webgl@khronos.org.
>>> >> To unsubscribe, send an email to majordomo@khronos.org with
>>> >> the following command in the body of your email:
>>> >> unsubscribe public_webgl
>>> >> -----------------------------------------------------------
>>> >>
>>>
>>>
>>>
>>> --
>>> Mikko Mononen, Software Engineer
>>> http://tinkercad.comÂ- Solid modeling for artists & makers
>>>
>>> -----------------------------------------------------------
>>> You are currently subscribed to public_webgl@khronos.org.
>>> To unsubscribe, send an email to majordomo@khronos.org with
>>> the following command in the body of your email:
>>> unsubscribe public_webgl
>>> -----------------------------------------------------------
>>>
>>
>
>
>
> --
> Mikko Mononen, Software Engineer
> http://tinkercad.comÂ- Solid modeling for artists & makers
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------