"Graphics" vs "UI" areas

[Hunter Freyer]

Hey Emircan,

In fxrev.dev/662233, you changed the name of the "Graphics" functional area to "UI." I just noticed that change, so I'd like to understand the thinking behind it.

"UI" is a very broad term, encompassing multiple other functional areas: HCI, View System, and arguably Experiences. "Graphics" is much more constrained, as described in the blurb:

The set of APIs that are used to transport and compose images on the system. It

includes interfaces for communicating with graphics hardware, as well as

scene-graph communication between Scenic and the rest of the system (not

including higher-level concepts such as views, see the [View

System](#view-system) area for that).

Currently, I think we ought to revert that CL and change the area back to "Graphics", but I'd like to understand any issues with that.

Thanks,

Hunter

[Emircan Uysaler]

It was a decision we made in a team meeting about docs. I believe the suggestion came specifically because of elements like Views and ViewSystem falling under both categories of Graphics and UI. Since our APIs(Flatland) are strongly coupled with input, we decided to go for the broader area of UI. If we split again, we need to make sure these overlaps make sense. For now, placed all docs under Concepts/UI.

I trust you to make the right call about doc organization, so please go ahead with any change you have in mind.

[Dave Schuyler]

Peanut gallery: I'm not directly involved here, feel free to ignore this, but I'll share some observations from earlier in my career, in they hope that they are helpful.

I have several decades experience* in game engines which I think are a parallel to this topic. It's difficult to maintain a separation of interests, and graphics engines (game engines) tend to encompass all things over time. First it's just about graphics, then:

• To get really responsive graphics, ya need fast IO, so IO becomes part of graphics.
• To get really responsive IO, ya need control of the memory, so memory becomes part of graphics.
• To get really responsive user input, ya need a direct feed of actions, so input becomes part of graphics.
• To get the audio and graphics to align properly, ya need accurate triggers/timing, so audio becomes part of graphics.
• (This list goes on with stuff like animation, physics, collision detection, latency compensation, networking, etc.)
• Eventually this gets so complex that troubleshooting with normal tools is difficult, so logging and debugging tools become included too.
• Less a factor now, but with spinning disks, the layout on disk became important, so asset packaging and installation may got pulled in as well.

At some point it becomes too much and the topics get separated again**.

I'm not sure if the treadmill above is good or bad. It sounds inefficient on the surface, but maybe it's part of the growth cycle - i.e. take all this with a grain of salt.

Aside: I've decided to try to avoid this cycle for the Fuchsia SDK, which is why the SDK team is so small. It could be driven in the opposite direction, I mean, what's not tied to the SDK in some way? For the SDK specifically, I don't think the cycle above will be helpful. YMMV.

* (six custom engines from roughly 1995 to 2006 - though I only did the graphics in the first couple, graphics is highly specialized work. I was more involved with bringing in the other pieces, so I have a heightened view of that aspect) 

** While this might repeat if given the time, most engines were only used for a set of titles/products (a few years) and then a new game engine is created, so I don't have empirical knowledge on whether this would cycle indefinitely and I've been out of the industry for seven years now.

--
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAN1f08dkoiMjNFh7AtBT2_A1sTtGM8X8gwhL%3Dv-xCE7mrEOZ5A%40mail.gmail.com.

[Hunter Freyer]

Ah, the YAML files under //docs/contribute/governance/ are about project governance (naturally), not around documentation. 

I've prepped a CL to revert those specific paths. I'm totally fine replacing "Graphics" with "UI" in the glossary. There's already a number of "areas" in the glossary that don't have corresponding areas on the API council.

Thanks,

Hunter

[Jaeheon Yi]

Thanks Hunter. 

Do we need some more specific OWNERS files for governance directories?

David - sounds like you have a lot of super-interesting experience! Would love to hear some stories, if you'd like to share. :-)

Jaeheon

--

You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAMkOBfsiqFfc%2Bq3P0G3XAzr62g6EAyXrFK1czj6F0Cev30%3DXkw%40mail.gmail.com.

[Emircan Uysaler]

Thanks Hunter. Your partial revert CL looks good. Looking back at it, rfc folder modification was more of a drive-by, not the main intention. Sorry that we missed the API council review for that.

+1 on hearing more from David as it feels so familiar. Any "graphics jank" bug gives us a journey through the entire OS.

[Hunter Freyer]

On Wed, Jul 6, 2022 at 4:20 PM Emircan Uysaler <emi...@google.com> wrote:

Thanks Hunter. Your partial revert CL looks good. Looking back at it, rfc folder modification was more of a drive-by, not the main intention. Sorry that we missed the API council review for that.

No worries!

 

+1 on hearing more from David as it feels so familiar. Any "graphics jank" bug gives us a journey through the entire OS.

Yeah, incidentally, I don't think it'd be unreasonable to say that these areas are so tightly coupled that it'd be better to merge them. But that'd be something for the API Council to vote on.

 

On Wed, Jul 6, 2022 at 3:26 PM Jaeheon Yi <jae...@google.com> wrote:

Thanks Hunter. 

Do we need some more specific OWNERS files for governance directories?

Turns out that I'm not even an OWNER on the governance directories :). I've sent https://fuchsia-review.googlesource.com/c/fuchsia/+/698059 to fix that, and to start a conversation on whether the docs team wants to be OWNERS or not.

Thanks,

Hunter

[John Bauman]

On Wed, Jul 6, 2022 at 3:55 PM 'Hunter Freyer' via api-council <api-c...@fuchsia.dev> wrote:

On Wed, Jul 6, 2022 at 4:20 PM Emircan Uysaler <emi...@google.com> wrote:

Thanks Hunter. Your partial revert CL looks good. Looking back at it, rfc folder modification was more of a drive-by, not the main intention. Sorry that we missed the API council review for that.

No worries!

Yeah, that partial revert looks good. 

 

+1 on hearing more from David as it feels so familiar. Any "graphics jank" bug gives us a journey through the entire OS.

Yeah, incidentally, I don't think it'd be unreasonable to say that these areas are so tightly coupled that it'd be better to merge them. But that'd be something for the API Council to vote on. 

 Seems reasonable to me.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAMkOBfsLZZ3pd4tneHQ6MVV0NK_bJR25Fc6C46XU%2Befu%3DjCEXA%40mail.gmail.com.

[Alice Neels]

+1 to all this. I think specifically for API review it's useful to maintain some separation of concerns for graphics vs. HCI vs. view system vs. related areas, since it'll prompt us to have better conversations about who is the best reviewer for the specific CL, and whether our organization makes sense. There's quite a bit of API surface here with a bunch of specialized knowledge + security concerns, and specialized reviewers definitely add value.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAAr6sCduC6rhj6w%3D8v%2B%2BhjY6Y-GL3WHh_2MZFxkgTiBN_iTKhA%40mail.gmail.com.