[Merge] lp:~gerboland/qtubuntu/adopt-more-eglconvenience2 into lp:qtubuntu

Gerry Boland gerry.boland at canonical.com
Fri May 27 13:59:31 UTC 2016


> I guess we can get rid of this long waiting one [1] then (I still need to
> validate that there's nothing missing from there, but it doesn't seem so).

Yep done.

> I don't remember exactly the details of [2] (IIRC I saw that somewhere in the
> Qt code base) but what do you think of not forcing the alpha size to 8 if not
> specified by the user? I guess if the user doesn't set the alpha size
> explicitely, he doesn't want his surface to support translucent surface
> anyway. You could then use mFormat instead of mWindow->requestedFormat()
> there: "if (mWindow->requestedFormat().alphaBufferSize() < 0) {".

I did this actually to start with. But unless I'm mistaken, the QML renderer requires an alpha channel in order to do blending correctly. This is why I enforced an alpha channel being requested. I too would like to clarify this, because what you suggest does make more sense.


> Also, as it's done in [2], what do you think of forcing undefined color
> channels to 8 independently from the others instead of setting all of them to
> to 8 only if all are undefined? It sounds like a more predictive use case to
> me.
Well I presumed that if a user sets any channel size, then I'll assume they know what they're doing and so leave them alone. If they ask for RGB565, I'm not going to turn on alpha channel for them.


> The env var part could be useful too for us to check the behaviour of some
> platforms. But that's definitely not a priority.
True, that is nice. I'll include that.
-- 
https://code.launchpad.net/~gerboland/qtubuntu/adopt-more-eglconvenience2/+merge/295248
Your team Ubuntu Phablet Team is subscribed to branch lp:qtubuntu.



More information about the Ubuntu-reviews mailing list