728961 - Track GL state carefully

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Joe Drew (not getting mail)]

In bug 728631, Chris Lord made the point that we really just litter our GL calls with glEnable(whatever) for whatever we need. We should, instead, just initialize to the state we want, and only ever change it if we *don't* want it to be that state.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

I believe it may be better to handle this with immutable state blocks like D3D does.

Before each draw we can set the appropriate state block. We then do a pointer comparison to check that the state is correct. If it's not then we can compute the difference between the states and apply those changes.

Comment 2

[Chris Lord [:cwiiis]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
> I believe it may be better to handle this with immutable state blocks like
> D3D does.
> 
> Before each draw we can set the appropriate state block. We then do a
> pointer comparison to check that the state is correct. If it's not then we
> can compute the difference between the states and apply those changes.

+1 on this - we found that removing unnecessary state changes can be quite a performance boost while developing Clutter, as well as helping tidy things up.

Comment 3

[Benoit Girard (:BenWa)]

Let's get a design ready so that someone can start on this when somebody is free. Do we want something for GL only or something flexible for D3D to use?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Benoit Girard (:BenWa) from comment #3)
> Let's get a design ready so that someone can start on this when somebody is
> free. Do we want something for GL only or something flexible for D3D to use?

D3D's state handling is already much saner than GL. Let's limit the scope to GL for now.

Comment 5

[Chris Lord [:cwiiis]]

Perhaps it'd be good to bundle this task with a COGL-based layers back-end? http://wiki.clutter-project.org/wiki/Cogl

Cogl solves a lot of the problems we're about to re-engineer (state-tracking, journalling, batching, atlasing, slicing, gles/gl abstraction, etc.)

Comment 6

[Benoit Girard (:BenWa)]

I took a look, I'm interested but it sounds like a lot of work to integrate.

Comment 7

[Chris Lord [:cwiiis]]

(In reply to Benoit Girard (:BenWa) from comment #6)
> I took a look, I'm interested but it sounds like a lot of work to integrate.

It would, though I think a cogl-based layers backend would be a lot less code than the current GL one and be more portable/performant.

It would be more work than adding GL state tracking, but that isn't an insignificant amount of work either... Is it worth exploring this? (I think so, but may be biased)

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

Not blocking on the assumption that this work is future work. If this is needed for the beta or final release please renom.

Comment 9

[Joe Drew (not getting mail)]

This is actually a general issue, not a maple-specific issue.

Comment 10

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.